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Abstract 



A shadow function block (108) has a communications port with an Input that communicates with an external function 
block (112) via the communication network. This is done to receive data pertaining to the external function block. A 
memory (156) stores the received data pertaining to the external function block, according to a configuration protocol 
of the internal function block (1 52). Independent claims are also included for (1 ) A controller adapted to be 
communicatively coupled to a number of field devices, and (2) A method of implementing a control routine within a 
process controller. 
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Die f olgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

(g) Interface in Fornr» eines Schattenfunktionsblockes fur die Verwendung in einem Prozessregelnetzwerk 
(§) Ein ProzeHkontroller, der koinmunikativ miteiner Gxter- 

nen Bereichsvorrichtung uber ein Kommunikationsnetz- 

werk gekoppelt 1st, verwendet eineh Schattenfunktions- . 

block, der innerhalb eiries ProzeSkontrollers angeordnet ' . . 

ist, um eine Implementierung einer Steuer- oder Regel- 

foutine zu ermpglichen, die sowohl einen internen Funk- • 
. tionsblock, der innerhalb des ProzefSkontrollers angeord- 
net ist, als aiich einen externen Funktionsblock, der inner- 
halb. der externen Bereichsvorrichtung angeordnet ist, 
verwendet. Der Schattenfunktionsblock enthalt einen 
Kommunikationsport, der mit dem externen Funktions- 
block uber das Kommunikationsnetzwerk kommuniziert, . 
um dadurch Daten, die den externen Funktionsblock be- 
treffen^ zu empfangeri, enthalt einen Speicher, der die 
empfangenen Daten gemaf^ eineni Konfigurationsproto- 
koll des internen Funktionsblocks separiert, und einen 
Ausgang, der die gespeicherten externen Funktionsblock- 
daten in den internen Funktionsblock gemaB dem Konfi- 
■ gurationsprbtokoll des internen Funktionsblocks liefert. 
Der Kommunikationsport des Interface-Funktionsblocks 
kann einen Ausgang enthalten, der Daten, die durch den 
Kontroller oder den internen Funktionsblock erzeugt wor- 
den sind, zu dem externen Funktiohsblock.unter Verwen- 
dung des Kommunikationsprotokolls sendet, welches 
dem externen Funktionsblock zugeordnet ist. 
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Beschreibung 

Die v'orliegende Erfindung betrifft ProzeBregelnetzwerke 
und spezieller einen ProzeBkontroller, der Schattenfunkti- 
onsblocke verwendet, um Informationen wiederzugeben, 
die extemen Funktionsblocken zugeordnet sind, welche in 
einem ProzeBregelnetzwerk verteilt sind. 

ProzeBregekietzwerke, wie beispielsweise solche, die in 
chemischen, Mineralol- odea: anderen Prozessen verwendet 
werden, enthalten im allgemeinen einen zentralisierten Pro- 
zeBkontroller; der kommunikativ mit einer oder mehreren 
Gebiets- oder Bereichsvorrichtungen gekoppelt ist, die bei- 
spielsweise Ventilstellglieder, Schalter, Sensoren (wie z. B. 
Temperatur-, Druck- und Stxomungsratensensoren) usw. 
sein konnen. Diese Bereichsvorrichtungen konnen Steuer- 
funkdonen innerhalb des Prozesses durchfiihren (wie das 
Offhen oder Schlie6,en eines Ventils), konnen Messungen 
innerhalb des Prozesses vomehmen, die fOr die Steuemng 
oder Regelung der Arbeitsweise des Prozesses verwendet 
werden, oder konnen irgendeine andere gewiinschte Funk- 
tion innerhalb des Prozesses ausfiihren. ProzeBregler wur- 
den in historischer Weise an die Bereichsvorrichtungen iiber 
eine oder mehrere analoge Signalleitungen oder Busse ange- 
schlossen,. die beispielsweise 4-20 mA (Milliampere) Si- 
gnale zu und von den Bereichsvorrichtungen leiten. Allge- 
mein gesagt, empfangt der ProzeBkontroller Sighaie, welche 
die Messungen angeben, die durch einen oder durch meh- 
rere Bereichsvorrichtungen vorgenommen wurden und/oder 
andere Informationen anzeigen, die zu einer oder zu mehre- 
ren Bereichsvorrichtungen gehoren, und er verwendet diese 
Informationen, um eine typische komplexe Steuerroutine zu 
implementieren, und erzeugt dann Steuersignale, die iiber 
die analogen Signalbusse zu einer oder mehreren der Be- 
reichsvorrichtungen' gesendet werden, um dadurch den Be- 
trieb des Prozesses zu steuem. 

Kiirzlich kamBewegung in die ProzeBregel-^ oder-steuer- 
industrie, um bereichsbasierende digitale Kommunikatio- 
nen in der ProzeBregelumgebung zu implenlentieren. Bei- 
spielsweise hat die ProzeBregelindustrie eine Anzahl von of- 
fenen, digitalen oder kombinierten digitalen und analogen 
StandardkommunikationsprptokoUen entwickelt, wie bei- 
spielsweise die HART®, PROFffiUS®, WORLDFIP®^ De- 
vice-Net® und CAN-ProtokoUe. Diese digitalen Kommuni- 
kationsprotokolle ermoglichen es mehreren Bereichsvor- 
richtungen, an einen bestinmiten Bus angeschlossen zu wer-. 
den, sie unterstutzen mehrere und schnelle Kommunikatio- 
nen zwischen den Bereichsvorrichtungen und dem Kontrol- 
ler und/oder ermoglichen es den Bereichsvorrichtungen, 
mehrere und unterschiedliche Typen von Informationen, 
wie beispielsweise Informationen, die den Status und die 
Konfiguration der Bereichsvorrichtung selbst betreffen, zu 
dem ProzeBkontroller zu senden. Femer ermoglichen es 
diese digitalen StandardprotokoUe den Bereichsvorrichtun- 
gen, die von unterschiedlichen HersteEem hergestellt wur- 
den, zusammen imt dem gleichen ProzeBregelnetzwerk ver- 
wendet zu werden. 

> Auch gibt es nunmehrBewegung innerhalb der ProzeBre- 
gelindustrie, die ProzeBregelung oder -steuemng zu dezen- 
tralisieren, wodurch die ProzeBkontroller vereinfacht wer- 
den. Eine dezentralisierte Steuemng oder Regelung wird da- 
durch erhalten, daB bereichsmontierte ProzeBsteuervorrich- 
tungen, wie beispielsweise Ventilstellglieder, Sender usw., 
eine oder mehrere ProzeBsteuerfunktionen durchfiihren, und 
zwar unter Verwendung yon Einrichtungeh, die in typischer 
Weise als Fiinktionsblocke bezeichnet werden, und indem 
dann Daten iiber eine Busstmktur fur die Verwendung durch 
andere ProzeBsteuervorrichtungen (oder Funktionsblocke) 
bei der Ausfiihmng anderer Steuerfunktionen iibertragen 
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werden. Um diese Steuerfunktionen zu implementieren, ent- 
halt jede ProzeBsteuervorrichtung in'typiseher Weise einen 
Mikroprozessor mit der Fahigkeit, einen oder mehrere 
Funktionsblocke zu implementieren, als auch die Fahigkeit, 
mit anderen ProzeBsteuervorrichtungen zu kommunizieren, 
und zwar unter Verwendung eines offenen Standardkommu- 
nikationsprotokoUs. In dieser Weise konnen Bereichsvor- 
richtungen innerhalb eines ProzeBregelnetzwerks miteinan- 
der verbunden werden, um miteinander zu kommunizieren 
und um eine oder mehrere ProzeBsteuerfunktionen unter 
Bildung einer Regelschleife durchzufiihren, und zwar ohne 
Einschreiten eines zentralisierten ProzeBkontrollers, Das ge- 
samtdigitale Zweidraht-BusprotokoLL, welches durch die 
Fieldbus Foundation entworfen wird, bekannt als FOUN- 
DATION (eingetragene Marke) Fieldbus- (im folgenden als 
"Fieldbus" bezeichnet) Protokoll bekannt ist, ist ein offenes 
KommunikalionsprotokoU, welches es den Vorrichtungen, 
die von unterschiedlichen Herstellem stanmien, ermoglicht, 
untereinander zusammenzuarbeiten und zu kommunizieren, 
und zwar iiber einen Standardbus, um eine dezentralisierte- 
Steuemng innerhalb es Prozesses zu bewirken. 

Da digitale KommunikationsprotokoHe und dezentrali- 
sierte Steuemngsschemata (wie solche, die in der Fieldbus- 
Steuer- oder -Regelumgebung verwendet werden) so neu. 
sind, verwenden Prozesse, welche diese ProtokoUe imple- 
mentieren, diese lediglich in einem eingeschrankten Aus^ 
maB. Als ein Eigebnis unterstiitzen neuere ProzeBkontroller, 
wie der Delta V- (eingetragene Marke) ProzeBkontroller, der 
durch Fisher-Rosemount Systems hergestellt wird, sowohl 
analoge als auch digitale KommunikationsprotokoUe und es 
kann eine Hardware so programmiert werden, um die Steue- 
mng in einem ProzeB zu implementieren, der Bereichsvor- 
richtungen enthalt, die unter Verwendung von analogen 
StandardprotokoUen kommunizieren, wie beispielsweise ei- 
nem 4-20 mA ProtokoU, und unter Verwendung von einem 
Oder mehreren neueren digitalen Protokollen, wie dem 
Keldbus-ProtokoU. 

Es stellten sich jedoch Probleme ein, wenn versucht 
wurde, die Steuemng von analogen und digitalen Bereichs- 
vorrichtungen zu integrieren, und zwar spezieLL bei den 
Fieldbus-Bereichsyorrichtungen in einem ProzeBregelnetz- 
werk, welches einen zentralisierten KontroUer verwendet. 
. Da die Steuerfunktionen fiir analoge Bereichsvorrichtungen 
und einige digitale Bereichsvorrichtungen innerhalb des 
zentralisierten ProzeBkontroUers implementiert sind, wer- 
den alle erforderUchen Informationen uber diese Bereichs- 
vorrichtungen innerhalb des zentralisierten ProzeBkontrol- . 
lers.empfangen und gespeichert. Dies rhacht es seinerseits 
moglich, daB der zentraHsierte ProzeBkontroller die Steue- 
mng uriterschiedlicher analoger und digitaler Bereichsvor- 
richtungen integriert, die die momentane Konfiguration und 
Zustand von Abschnitten des ProzeBregelnetzwerks dar- 
steUt, in welchem diese Vorrichtungen gelegen sind, um An- 
derungen in derProzeBregelnetzwerkkonfiguration in bezug 
auf diese Vorrichtungen usw. vorzunehmen. Wenn jedoch 
ein dezentralisiertes Steuerschema, wie beispielsweise das 
Fieldbus-Steuerschema in einem Teil des Prozesses verwen- 
det wird, braucht der zentralisierte ProzeBkontroller keinen 
direkten Zugriff mehr auf aU die laufenden Informationen zu 
haben, die durch die ProzeBsteuervorrichtungen verwendet 
werden oder diesen zugeordnet sind, die der dezentralisier- 
ten Steuemng unterworfen sind. Tatsachlich sind einige de- 
zentralisierte ProzeBsteuerprotokoUe, wie beispielsweise 
das Fieldbus-ProtokoU, spezifisch so ausgelegt, daB es nicht 
erforderlich ist, Informationen zu einem zentralisierten Pro- 
zeBkontroller auf einer regularen Grundlage zu senden, 
Diese Tatsache macht es fiir den zentralisierten ProzeBkon- 
troller schwierig, die Steuemng von analogen oder anderen 
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digitalea Bereichsvorrichtiingen mit den Bereichsvorrich- 
txingen zu integrieren, die der dezentralisierten Steuerung 
imterworfen sind. Es macht es auch fiir den zentralisierten"^ 
PfozeBkohtxoller ischwierig, den laufenden oder momenta- 
nen Zustand der Vorrichtungen als Modell nachzubilden 
oderdarzustellen, die der dezentralisierten Steuerung unter- 
worfen sind, oder dies innerhalb eines dezentralisierten Ab- 
schnitts des ProzeBregelnetzwerks durchzufiihren. 

Tatsachlich miissen fiir den zentralisierten ProzeBkontrol- 
ler, der die Informationen von dem dezentralisierten Steuer- 
abschnitt des ProzeBregelnetzwerks empfangt, die Bereichs- 
vomchtungen (oder Funktionsblocke) innerhalb dieses Ab- 
schnitts des Prozesses spezifisch konfiguriert sein, um Infor- 
mationen direkt zu dem zentralisierten ProzeBkontroiler zu 
senden (was bedeutet, da6 der zentralisierte ProzeBkontroi- 
ler all diese Informationen empfangen und handhaben muB, 
wobei der groBte Teil derselben fur die Betriebsweise des 
zentralisierten ProzeBkontrollers nicht erforderlich ist). Al- 
ternativ muB der zentralisierte ProzeBkontroiler aktiv anfira- 
gen, um die von ihm. benotigten Informationen zu empfan- 
gen. Da solch einer Anfrage keine hohere Prioritat in bei- 
spielsweise dem Fieldbiis-Protokoll gegeben wird, und zwar 
zu der Zeit, in der der zentralisierte ProzeBkontroiler die an- 
gefragten Informationen empfangt, konnen diese Informa- 
tion veraitet sein. Es ist femer fiir den zentralisierten Pro- 
zeBkontroiler schwierig, wenn nicht unmogHch, Daten an- 
zufragen und zu empfangeii, die zu einer spezifizierten Zeit 
oder Zeitpuhkt aktiv oder momentan vorhanden sind. Statt 
dessen empfangt der zentralisierte ProzeBkbntroUer ledig- 
lich die Daten zu dem Zeitpunkt, zu welchem die Anfrage 
die Bereichsvorrichtung erreicht. Darilber hinaus ist die 
Kommunikation zwischen dem zentralisierten ProzeBkon- 
troiler und den Bereichs vorrichtungen innerhalb des dezen- 
tralisierten Abschnitts des Prozesses hoch speziahsiert und 
erfordert ein betrachtliches Wissen iiber das dezentralisierte 
Steuerprotokoll, was es fiir den Konstrukteur oder Entwick- 
ler der zentralisierten ProzeBsteuerroutine schwierig macht, 
diese Kommunikation auf einer gewiirischten Basis zu im- 
plementieren. 

• Die vorliegende Erfindung zielt auf die Verwendung von 
Schattenfunktionsblocken ab, um in einem zentralisierten 
ProzeBkontroiler die Steuerung der Funktionsblocke, die in 
dem zentralisierten Kontroller vorherrschen, mit solchen zu 
integrieren, die in einer extemen Vorrichtung vorherrschen, 
wie beispielsweise einer Bereichsvorrichtung. Die vorlie- 
gende Erfindung kann auch dafur verwendet werden, einem 
Kontroller die Moglichkeit zu geben, Vorrichtungen oder 
Funktionsblocke zu steuem oder mit diesen zu kbmmunizie- 
ren, die in' eiriem Konmiunikationsnetzwerk gelegen sind 
oder die ein KommunikationsprotokoU verwenden, welches 
von demjenigen verschieden ist, welches der Kontroller ver- 

■ wendet. Speziell wird ein Schattenfunktionsblock in dem 
zentralisierten Kontroller erstellt oder eingerichtet, um die 
Daten, die einem extemen Funktionsblock zugeordnet sind, 
der in einer extemen Vorrichtung, wie beispielsweise einer 
Bereichsvorrichtung, gelegen ist, zu spiegelri, und zwar in 
Eiriklang mit einem dezentralisierten Steuer- und Kommu- 
nikationsprotokoU. Die Steuerroutine des zentralisierten 
Kontrollers kommuniziert mit dem extemen Funktionsblock 
iiber den Schattenfunktionsblock, so als ob der exteme 
Funktionsblock durch den zentralisierten KontroUer imple- 
mentiert ware. Der Schattenfunktionsblock erhalt automa- 

. tisch die momentanen Informationen, die dem extemen 
Funktionsblock zugeordnet sind, und sendet Befehle zu dem 
extemen F'unktionsblock unter Verwendung des ProtokoUs, 
welches dem extemen (z. B. dezentralisierten) Steuerproto- 
koll zugeordnet ist. Im FaUe eines Fieldbus-ProtokoUs.wird 
diese Kommunikation unter Verwendung von sowohl syn- 



chronen als auch asynchronen Kommunikationen erreicht 
Jedoch kommuniziert der Schattenfunktionsblock mit ande- . 
ren Funktionsblocken inneriialb des zentralisierten Kontrol- 
lers so, als ob der exteme Funktionsblock vollstandig durch 

* 5 . den zentralisierten Kontroller implementiert ware. 

Unter Verwendung des Schattenfunktionsblockes der vor- 
liegendeii Erfindung kann die zentralisierte ProzeBsteuer- 
routine auf den neuesten Stand gebrachte Informationen um 
den tatsachlichen Funktionsblock hemm in einer Realzeit 

10 Oder nahezu auf Realzeitbasis empfangen, da diese Informa- 
tionen in dem Schattenfunktionsblock gespiegelt werden, 
der immer fiir die zentralisierte ProzeBsteuerroutine zugang- 
lich ist. In ahnlicher Weise kann die zentralisierte ProzeB- 
steuerroutine Befehle zu dem tatsachlichen Funktionsblock 

15 dadurch senden, indem sie einen Befehl zu dem Schatten- 
funktionsblock ungeachtet des Typs oder der Lage der Vor- 
richtung sendet, in welcher der tatsachliche Funktionsblock 
gelegen ist. Der Schattenfunktionsblock setzt dann diesen 
Befehl unmittelbar in Verbindung zu dem tatsachlichen 

20 Funktionsblock unter Verwendung geeigneter Kommiinika- 
tionsbefehle, die dem dezentralisierten ProzeBsteuerproto- 
kon zugeordnet sind, Auf diese Weise braucht die zentrali- 
sierte ProzeBsteuerroutine keine signifikante Datenbasis- 
steuemng in bezug auf die Bereichsvorrichtungen durchzu- 

25 fiihren, und zwar innerhalb des dezentralisierten Steuerab- 
schnitts des Prozesses, da die Informationen, die sie fiir die 
Bereichsvorrichtungen innerhalb des dezentralisierten Ab- 
schnitts des ProzeBregelnetzwerks, in dem Schattenfunkti- 
onsblock bzw. den Schattenfunktionsblocken gelegen sind. 

30 In ahnlicher Weise braucht die zentralisierte ProzeBsteuer- 
routine nicht spezifische programmiert zu werden, ura mit 
den komplexen und fordemden Aufgaben der Kommunika- 
tion in dem dezentralisierten ProzeBsteuerprotokoU fertig zu 
• werden, da diese Kommunikation automatisch durch den 

35 Schattenfunktionsblock durchgefuhrt wird. 

GemaB einem Aspekt der vorliegenden Erfindung ist ein 
Interface oder Schattenfunktionsblock dafur ausgebildet, 
um in einem ProzeBkontroiler verwendet zu werden, der 
kommunikativ mit einer extemen Vorrichtung iiber ein 

40 Kommunikationsnetzwerk gekoppelt ist, um dem ProzeB- 
kontroiler die Moghchkeit zu geben, eine Steuerroutine un- 
ter Verwendung von sowohl dem intemen Funktionsblock, 
der in dem ProzeBkontroiler vorherrscht, als auch eines ex- 
temen Funktionsblockes, der innerhalb der externen Vor- 

45 richtung vorhanden ist, zu implementieren. Das Interface 
oder der Schattenfunktionsblock gemaB diesem Aspekt der . 
Erfindung enthalt einen Kommunikationsport mit einem 
Eingang, der mit dem extemen Funktionsblock iiber das 
Kommunikationsnetzwerk kommuniziert, um dadurch Da- 

50 ten zu empfangen, die zum extemen Funktionsblock geho- 
ren, und enthalt einen Speicher, der die empfangenen Daten, 
die zu dem extemen Funktionsblock gefioren, gemaB einem 
KonfigurationsprotokoU des intemen Funktionsblockes 
speichert. Wenn es erwiinscht ist, kann der Interface-Funk- 

55 tionsblock auch einen Ausgang aufweisen, der die gespei- 
cherten extemen Funktionsblockdaten zu dem intemen 
Funktionsblock liefert, und zwar unter Verwendung des 
Konfiguratiorisprotokolls des intemen Funktionsblocks. In 
ahnlicher Weise kann der Kommunikationsport des Inter- 

60 face-Funktionsblocks einen Ausgang enthalten, der Daten 
(wie beispielsweise verketteterDaten oder Befehle) zu dem 
extemen Funktionsblock sendet, und zwar unter Verwen- 
dung eines KommunikationsprotokoLLs, welches dem exter- 
nen Funktionsblock zugeordnet ist. 

65 In bevorzugter Weise enip^gt der Kommunikationsport 
des Interface-Funktionsblocks die Daten, die zu dem exter- 
nen Funktionsblock gehoren, unabhangig von der Operation 
der intemen Funktionsblocke. In ahnlicher Weise konrniunir 
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ziert bei einer Ausfuhningsform der exteme Funktionsblock 
iiber das Kommunikationsnetzwerk unter Verwendung eines 
ersten KommunikationsprotokoUs, welches verschieden ist 
vori einem zweiten KornmunikationsprotokoU, welches dem 
internen Punktionsblock zugeordnet ist, und in diesein Fall 
kommuniziert der Kominunikationsport mit dem extemen 
Funktionsblock unter Verwendung des ersten Kommunika- 
tionsprotokoUs und der Ausgang des Interface-Funktions- 
blocks kommuniziert mit dem internen Funktionsblock ge- 
maB dein zweiten Kommunikationsprotokoll. 

Wenn es gewunscht wird, kann das erste Kommunikati- 
onsprotokoll, welches dem extemen Funktionsblock zuge- 
ordnet ist, ein Fieldbus-Kommunikationsprotokoll sein. In 
diesem Fall kann der Xommunikationsport eine Interface- 
vorrichtung (wie beispielsweise eine Interfacekarte) ver- 
wendeh, die dafiir konfiguriert ist, um mit der extemen \br- 
richtung unter Verwendung des Fieldbus-Kommunikations- 
protokoUs zu kommunizieren, um dadurch eine Kommuni- 
kation mit dem extemen Funktionsblock vorzunehmen. per 
Kommunikationsport kann beispielsweise mit dem extemen 
Funktionsblock unter Verwendung synchroner Kommunika- 
tionen kommunizieren, wie beispielsweise die Herausgeber- 
/Teilnehmerbeziehungeii des Fieldbus-Kommunikations- 
protokoUs und/oder kann asyncfarone Kommunikationen 
verwenden, wie z. B. die Betrachtungsobjekte in dem Field- 
biis-KommtinikationsprotokolL Allgemeiner kann die ex- 
teme Vorrichtung unter Verwendung eines Vorrichtungs- 
Kommunikationsprotokolls kommunizieren, welches die 
Kommunikation der logisch verketteten Pakete an Daten un- 
ter Verwendung von standardisierten Kommunikationsrufen 
. unterstutzt, wie beispielsweise die Betrachtungsobjekte und 
die Betrachtungswamungen des Fieldbus-Kommunikati- 
ohsprotokoUs, und es kann der Kommunikationsport mit 
dem extemen Funktionsblock unter Verwendung der stan- 
dardisierten Konununikationsrufe kommunizieren. In ahnli- 
cher Weise kann der Kommunikationsport Alarmanzeigen 
von dem extemen Funktionsblock empfangen und kann 
diese Alarmanzeigen in dem Speicher ftir die Verwendung . 
durch den Kontroller speichem; 

GemaB einem anderen Aspekt der vorliegenden Erfin- 
dung enthalt ein Kontroller, der dafiir geeignet ist, um kom- 
munikativ an eine Vielzahl von Bereichsvorrichtungen ge- 
koppelt zu werden, einen Speicher und eine Steuerroutine 
enthalten, die in dem Speicher abgespeichert ist und die 
durch den Prozessor implementiert ist, um die Vielzahl der 
Bereichsvorrichtungen zu steuem. Die Steuerroutine enthalt 
eine Vielzahl von miteinander verbundenen internen Funk- 
tionsblocken, die unter Verwendung eines Kontrollerproto- 
kolls. konfiguriert sind, so daB sie durch den Kontroller im- 
plementiert werden, und kann einen Interface-Funktions- 
block enthalten, der mit einem der miteinander verbundenen 
internen Funktionsblocken kommuniziert, unter Verwen- 
dung des KontrollerprotokoUs und der mit einem extemen 
Funktionsblock konomianiziert, der in einer extemen Be- 
reichsvorrichtung vorhandeh ist, und zwar unter Verwen- 
dung eines Bereichsvorrichtungs-Kommunikationsproto- 
koLLs. Der Interface-Funktionsblock speichert Daten, die zu 
dem extemen Funktionsblock gehoren und von dem exter- 
nen Funktionsblock fiir die Verwendung durch die Steuer- 
routine empfangen werden; 

GemaB einem weitereh Aspekt der vorliegenden Erfin- 
diing speichert ein Vafahren zum Implementieren einer 
Steuerroutine inneriialb eines ProzeBkontroUers, innerhalb 
des KontroUers eine Vielzahl von initeinaiider verbundenen 
internen Funktionsblocken, die gemaB einem KontroUerpro- 
tokoLL konfiguriert sind, um einen Teil der KontroUerroutine 
zu implementieren. Das Verfahren erzeugt auch innerhalb 
des KontroUers einen Interface-Funktionsblock, der gemaB 
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dem KontroUerprotdkoU konfiguriert ist, der jedoch mit ei- 
nem extemen Funktionsblock kommuniziert, der in einer 
extemen Bereichsvorrichtung gelegen ist, und zwar unter 
Verwendung eines Vorrichtungs-Kommunikationsproto- 
5_^ koUs, welches der exteriien Vorrichtung zugeordnet ist. Das 
Verfahren erzeugt dann eine Steuerroutine, welche die Mel- 
zahl der miteinander verbundenen internen Funktionsblocke 
und den Interface-Funktionsblock verwendet, um den Pro- 
zeB zu steuem oder zu regeln und wahrend der Implementie- 
mng der Steuerroutine werden Daten gespeichert, die dem 
extemen Funktionsblock zugeordnet sind und von diesem 
empfangen werden, lind zwar in dem Interface-Funktions- 
block fur die Verwendung durch die Steuerroutine, so als bb 
der extefne Funktionsblock durch den Kontroller als einer 
da: internen Funktionsblocke implementiert ware. 

Das Verfahren kann einem Anwender auch erlauben, die 
Steuerroutine dadurch zu konfigurieren, indem jeder eine 
Anzahl von Funktionsblocken, die in der Steuerroutine ver- 
wendet werden soUen, spezifiziert wird, die Verbindungen 
zwischen den spezifizierten Funktionsblocken, die in der 
Steuerroutine zu verwenden sind, identifiziert werden und 
die Stelle oder Ort eiiies bestimmten spezifizierten Funk- 
tionsblockes spezifiziert wird, und zwar als ein intemer 
Funktionsblock, der in dem Kontroller implementiert ist; 
oder als ein extemen Funktionsblock, der durch eine Be- 
reichsvoriichtung implementiert ist. In dem FaU, bei wel- 
chem ein Funktionsblock in einer extemen Vorrichtung zu 
implementieren ist, enthalt das Verfahren den Schritt gemaB 
einer Auswahl einer extemen Vorrichtung aus einer Liste 
oder einem Satz von Vorrichtungen, die in dem System ver- 
bunden oder angeschlossen sind. , 

Fig. 1 ist ein schematisches Blockschaltbild eines bei- 
spielhaften ProzeBregebietzwerks, welches zentralisierte 
und dezentralisierte ProzeBsteuerabschnitte darin enthalt; 

Fig; 2 ist ein schematisches Blockschaltbild von drei 
Standardfunktionsblocken, die einer oder mehreren Field- 
bus-Bereichs vorrichtungen zugeordnet sind; 

Fig. 3 ist ein Zeitsteuerschema fiir einen Makrozyklus ei- 
nes Segments eines. Fieldbus-Busses, der innerhalb des Pro- 
zeBregebietzwerks von Fig, 1 gelegen ist; 

Fig. 4 ist ein schematisches Blockschaltbild, welches die 
Verbindung eines Schattenfunktionsblockes mit anderen 
Funktionsblocken herausgreift, die einer zentraUsierten Pro- 
zeBsteuerroutine zugeordnet sind und innerhalb eines zen- 
tralisierten ProzeBkontroUers gelegen sind; 

Fig. 5 ist ein Blockdiagramm eines Teiles eines ProzeBre- 
gelsystems unter Verwendung des Schattenfunktionsblockes 
der vorliegenden Erfindung; 

Fig. 6 ist ein RuBdiagramm, welches die Installation ei- 
nes Steuermoduls innerhalb des KontroUers von Fig. 1 ver- 
anschauUcht; 

Fig. 7 ist ein FluBdiagramm, welches die InstaUation ei- 
nes aktiven VerbindungsgUedplans in dem Fieldbus-Ab- 
schnitt des /ProzeBregelnetzwerks von Fig. 1 veranschau- 

Hcht; 

Fig. 8 ist ein RuBdiagramm, welches die InstaUation von 
Veroffentlicher-BindegUedem in dem Fieldbus-Abschnitt 
des ProzeBregelnetzwerics von Fig. 1 yeranschauUcht; 

Fig. 9 ist ein RuBdiagramm, welches die InstaUation ei- 
ner Vorrichtungskonfigiiration in einer Vorrichtung inner- 
halb des Fieldbus-Abschnitts des ProzeBregelnetzwerks von 
Fig. 1 veranschauHcht; 

Fig, 10 ist ein RuBdiagramm, welches die InstaUation ei- 
nes Fiinktionsblockes innerhalb einer Vorrichtung in dem 
Fieldbus-Abschnitt des ProzeBregelnetzwerks von Fig.'l 
veranschauUcht; 

' Fig. 11 ist ein FluBdiagramm, welches die Betriebsweise 
des Funktionsblocks und darauf bezogener Komponenten 
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wahrend des Betriebs eines zentralisierten Steuermoduls 
veranschaulicht, und zwar unter Verwendung des Schatten- 
funktionsblockes; und 

Fig. 12 ist ein RuBdiagramm, welches die Kommunika- 
tion von Daten und von Schreibanfragen von einem Block in 5 
einem zentralisierten KontroUer oder einem Anwender zu 
einem extemen Funktionsblock in einer Bereichsvprrich- 
tung unter Verwendung des Schattenfunktionsblockes der 
Erfindung veranschaulicht. 

GemiB Fig. 1 ist ein ProzeBregelnetzwerk 10 in Block- 10 
diagrammform veranschaulicht. Das ProzeBregelnetzwerk 
10 enthalt einen zentralisierten PrbzeBkontroller 12, der eine 
ProzeBsteuerroutine, die in diesem gespeichert ist, imple- 
mentieren kann. Der Kontroller 12 kann, um hier lediglich 
ein Beispiel zu nennen, der DeltaV (eingetragene Marke) 15 
Kontroller sein, der durch Fisher-Rosemoiint Systems ver- 
trieben wird, und kann an verschiedene Workstations, wie 
bei spiels weise Personalcomputer (PCs)" 14 iiber einen Hub 
16 lind Ethernet- Verbindungen 18 verbunden sein. In dieser 
Kpnfiguration konnen die PCs 14 durch eine oder mehrere 20 
Beciienungspersonen oder Anwender verwendet werden, um 
mit dem ProzeBkontroller 18 eine Konmiunikation herzu- 
steUen, um dadurch Informationen zu erhalten, die das Pro- 
zeBregelnetzwerk 10 betreffen, um den Status des ProzeBre- 
geLhetzwerks 10 zu iiberblicken oder zu andem, um Infor- ,25 
mationen zu erhalten, die die einzelnen Bereichsvorrichtun- 
gen innerhalb des ProzeBregelnetzwerks 10 betreffen usw. 
Wenn der Kontroller 12 aus einem DeltaV- KontroUer be- 
steht, kann er einen graphischen Ausschnitt der ProzeB- 
steuer- oder -regelroutine innerhalb des KontroUers 12 zu 30 
dem Anwender Hefem, und zwar iiber einen der PCs 14, wo- 
bei die Funktionsblocke oder Steuerblocke innerhalb der 
ProzeBsteuerroutine veranschaulicht werden und auch die 
Art, in welcher diese Funktionsblocke miteinander verkettet 
sind, um die Steuerurig oder Regelung eines Prozesses zu 35 
bewirken. Der Anwender hat die Moghchkeit, die ProzeB- 
steuer- oder -regelroutine zu andem, und zwar innerhalb des 
zentralisierten ProzeBreglers 12, indem er den graphischen 
Ausschnitt der Funktionsblocke innerhalb der Steuer- oder 
Regelroutine manipuliert, um Funktionsblocke von dieser 40 
Steuerroutine . wegzulassen oder zu dieser hinzuzufiigen 
und/oder den Weg zu andem, in Welchem die Funktions- 
blocke, die der Steuerroutine zugeordnet sind, verkettet 
sind, das heiBt den Weg oder die Art, in welcher sie verbun- 
den sind. 45 

Wie in Fig, 1 dargesteUt ist, ist der zentralisierte Kontrol- 
ler 12 mit zahlreichen Bereichsvorrichtungen (field devices) 
verbunden, die iiber einen ProzeB^ hinweg verteilt gelegen 
sind (ailgemein durch das Bezugszeichen 19 angezeigt) . ^ 
Der zentralisierte Kontroller 12 kariii iiber irgendwelche 50 
Standardtypen I/O-Karten 20 und 22 mit den Bereichsvor- 
richtungen 26, 28, 30, 32, 34 und 36 kommunizieren, die der 
zentralisierten Steuemng von dem Kontroller 12 unterwor- 
fen sind. Die I/O-Karte 20 kann beispielsweise eine analoge 
I/O-Karte sein, die den Kontroller 12 mit analogen Be- 55 
rieichsvorrichtimgen 24 und 26 verbindet, die iiber 4-20- 
mA-Busse 38 kommunizieren. In ahnlicher Weise kann die 
I/O-Karte 22 eine digitale oder kombinierte digitale und 
analoge I/O-Karte sein, die mit digitalen oder gemischten 
digitalen und analogen Bereichsvorrichtungen in irgendei- 60 
nem gewiinschten Format kommuniziert, inklusive bei- 
spielsweise dem 4-20-mArAnalogformat oder irgendeinem 
bekannten oder standardisierten Digitalfomiat. Natiirlich 
konnen, die Bereichsvorrichtungen 26, 28, 30, 32, 34 und 36 
von. irgendeinem gewiinschten I^p von Bereichsvorrichtun- 65 
gen bestehen, beispielsweise aus Sendem, Sensoren, Ventil- 
steUgliedem, Ventilsteuervorrichtungen usw. Es sei in Ver- 
bindung mit dem Beispiel des in Fig, 1 veranschauUchten 



ProzeBregelnetzwerks 10 darauf hingewiesen, daB die Be- 
reichsvorrichtungen 26-36 Abschnitten des Prozesses 19 
zugeordnet sind, die eiher zentralisierten Steuemng durch 
die Steuerroutine innerhalb des KontroUers 12 unterworfMi 
sind. 

Der KontroUer 12 ist ebenfaUs kommunikativ mit einer 
Interfacekarte 40 verbunden, die ihrerseits mit (oder Teil ist 
von) einem extemen ProzeBregelnetzwerk, in welchem die 
PrbzeBregelung in einer verteilten Weise durchgefuhrt wird, 
oder welcher Vorrichtungen enthalt, die Funktionsblocke 
haben, die unter Verwendung eines Kommunikationsproto- 
koUs kommunizieren, welches verschieden ist von demjeni- 
ged, welches innerhalb des KontroUers 12 verwendet wird. 
Bei der in Fig, 1 veranschauUchten Ausfuhrungsform ent- 
halt der dezentraUsierte ProzeBsteuerabschnitt des Prozesses 
19 die Interfacekarte 40, einen Bus 42 und zahlreiche Be- 
reichsvorrichtungen 43, 44, 46, 48 und 50, die an den Bus 42 
angeschaltet sind. Das verteilte ProzeBregelnetzwerk von 
Fig. 1 kann beispielsweise ein Fieldbus-Netzwerk sein, wel- 
ches das Fieldbus-Konnnunikationsprotokoll verwendet. 
Wie im folgenden noch mehr in Einzelheiten erlautert wer- 
den wird, kann die Interfacekarte 40 eine aktive Verbin- 
dungsghed-Ablaufsteuemng sein, die dem Fieldbus-Kom- 
munikationsprotokoU zugeordnet ist. 

Die zentraHsierte ProzeBsteuerroutine, die innerhalb des 
KontroUers 12 gelegen ist, empfangt EingangsgroBen von 
den Bereichsvorrichtungen 26-36 und moglicherweise 
43-50, fiihrt Berechnungen und andere Aktivitaten durch, 
die mit der Steuerroutine verbunden sind, und sendet dann 
Befehle zu deri Bereichsvorrichtungen uber die I/O-Karten 
.20 und 22 und die Interfacekarte 40, um irgendeine ge- 
wiinschte Steuemng oder Regelung des Prozesses 19 zu im- 
plementieren. Es sei jedoch darauf hingewiesen, daB der de- 
zentraUsierte ProzeBsteuer- oder -regelabschnitt des ProzeB- 
regelnetzwerks 10 (das heiBt deijenige, der dem Bus 42 in 
Fig. 1 zugeordnet ist) seine eigene ProzeBsteuerroutine in 
einer dezentraUsierten Weise implementiereri kann, wie dies 
hier noch beschrieben wird, und zwar in Verbindung mit der 
Steuemng, die durch den KontroUer 12 ausgefiihrt wird. 
Wahrend somit der KontroUer 12 mit einer Steuemng ge- 
koppelt sein kann und eine gewisse Steuerung iiber die. Vor- 
richtungen 43-50, die an deri Bus 42 angeschlossen sind, 
ausfuhren- kann, konnen diese Vorrichtungen auch Steuer- 
funktionen implementieren oder Funktionsblocke, die mit 
der Steuemng verbunden sind, welche durch den KontroUer. 
12 implementiert wird, die jedoch statt dessen iiber die Vor- 
richtungen,. die an den Bus 42 angeschlossen sind, verteilt 
sind. 

' Wahrend bei der bevorzugten Ausfiihmngsform der de- 
zentraUsierte Abschnitt des ProzeBregelnetzwerks 10 das 
Fieldbus-Kommunikations- und -SteuerprotokoU verwen- 
det, kann irgendein anderes oder gewiinschtes ProtokoU 
ebenso verwendet werden, inklusive den ProtokoUen, die in 
der Zukunft entwickelt werden. Feraer kann der Schatten- 
fiinktionsblock, der hier offenbart ist, dazu verwendet wer- 
den, um eine Konmiunikation zwischen irgendwelchen zwei 
unterschiedUchen Steuer- oder KommunikationsprotokoUen 
durchziifiihren, und es Uegt keine Beschrankung auf die Ver- 
wendung zwischen einer zentraUsierten Steuerroutine und 
einem dezentraUsierten Steuer- oder Regelnetzwerk, wie 
beispielsweise auf eines, welches das Fieldbus-ProtokoU 
verwendet, vor. Es kann beispielsweise zwischen zwei un- 
terschiedUchen zentralisierten Steuerroutinen oder Proto- 
koUen, die Steuerblocke ehthalten, verwendet werden. Mit 
anderen Worten ist der hier beschriebenen Schattenfunkti- 
onsblock nicht darauf beschr^Jikt, mit Funktionsbldcken in 
dem Fieldbus-ProtokoU verwendet zu werden oder sogar 
mit einem ProtokoU, welches eirier dezentraUsierten Steuer- 
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routine zugeordnet ist, sondem kann auch dazu verwendet 
werden, einen Kontroller (oder andere Vorrichtung) dazu zu 
befahigen, mit irgendeiner anderen extemen Vorrichtung zu 
kommunizieren, die irgendeinen unterschiedlichen 1^ ei- 
nes KommunikationsprotokoUs verwendet. 

Bevor Hnzelheiten des Schattenfunktionsblockes der 
vorliegenden Erfindung erlautert werden und die Art, in 
welcher der zentralisierten ProzeBkontroller 12 solch einen 
Schattenfunktionsblock verwendet, um eine Steuerung in ei- 
nem ProzeBregelnetzwerk zu implementieren, folgt eine all- 
gemeine Beschreibung des Fieldbus-Protokolls, der Be- 
reichsvorrichtungen, die gemaJB diesem Protokoll konfigu- 
riert sind, und die Art, in welcher die Kommunikation in 
dem Abschnitt des ProzeSregelnetzwerks 10 erfolgt, der das 
Fieldbus-Protokoll verwendet. Es sei darauf hingewiesen, 
daB, obwohl des Fieldbus-Protokoll bereits ein relativ neues 
gesamtdigitales Konununikationsprotokoll ist, welches fur 
die .Verwendung iri einem ProzeBregelnetzwerk entwickelt 
wurde, dieses Protokoll auf dem Gebiet bekannt ist und in 
Einzelheiten in vielerlei Artikeln, Broschiiren und Beschrei- 
bungen beschrieben ist, die veroffentlicht, verteilt und von 
der Fieldbus Foundation unter anderem verfiigbar sind, ei- 
ner nicht auf Profit basierenden Organisation, die ihren Sitz 
in Austin, Texas, hat. Spe?iell ist das Fieldbus-Protokoll und 
die Art der Konmiunikation mit und die Art der Speicherung 
von Dalen in Vorrichtungen, die das Fieldbus-Protokoll ver- 
wenden, in Einzelheiten in den Bedienungsanleitungen be- 
schrieben, mit demTitel "Conununications Technical Speci- 
fication" und "User Layer Technical Specification" von der 
Fieldbus Foundation. 

AUgemein gesagt, besteht das Fieldbus-Protokoll aus ei- 
netn insgesamt digitalen, serielien Zweiwege-Kommunika- 
tionsprotokoll, welches eine standardisierte physikaHsche 
Schnittstelle'fur eine Zweidrahtschleife oder Bus schafft, die 
"Feld"-Ausrustungen, wie beispieisweise Sensoren, Stell- 
glieder, Kontroller, Ventile usw., miteinander verbindet, die 
in einer MeBgerateaiisriistung oder einer PfozeBsteuer- oder 
-regelumgebung gelegen sind, beispieisweise in einer Fa- 
brik Oder Ahlage. Das Fieldbus-Protokoll betrifft im Prinzip 
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gen insofem sind, als sie jeweils einen Mikroprozessor ent- 
halten, der eine Kommunikation durchfiihren kann und in 
einigen Fallen Steuerfunktionen durchfiihren kann), der 
aber ebenso erkennen kann, wenn neue Befeichsvorrichtun- 
gen an deri Fieldbus-Bus angeschlossen werden, wenn die 
Bereichsvorrichtungen von dem Bus entfemt werden, der 
Daten erkennen kann, die durch die Bereichsvorrichtungen, 
welche an den Bus angeschlossen sind, erzeugt werden, und 
der eine Kopplung mit einer oder mit mehreren Anwender- 
terminals bewirkt, die in dem Host oder irgendeiner anderen 
Vorrichtung gelegen sein k5nnen, welche in irgendeiner 
Weise an den Host angeschlossen sind. 

Der Fieldbus-Bus unterstiitzt oder erlaubt zweierlei: eine 
rein digitale Konmiunikation und er kann auch ein Strom- 
versorgurigssighal zu irgendeiner oder zu all den Vorrichtun- 
gen,. die an ihn angeschlossen sind, ubertragen, wie bei-' 
spielsweise an die Bereichsvorrichtungen. Altemativ kann 
irgendeine oder konnen alle Fieldbus- Vorrichtungen ihre ei- 
gene Stromversorgung besitzen oder konnen uber separate 
Leitungen mit externen Stromversorgungen verbunden sein. 
Das Fieldbus-Protokoll erlaubt es vielen VorrichtungenAfer- 
, drahtungstopologien, inklusive Vielfachvorrichtungen, an 
das gleiche Paar von Drahten oder Leitungen angeschlossen 
zu werden, erlaubt Punkt-zu-Piinkt-Verbindungen, in wel- 
chen jede Vorrichtung an einen Kontroller oder einen Host 
uber ein getrenntes Zweidrahtpaar angeschlossen ist (ahn- 
lich den typischen 4-20 mA Analogsystemen) und Baum- 
oder "spur"-Verbindungen realisiert sind, in denen jede Vor- 
richtung mit einem gemeinsarhen Punkt in einem Zweilei- 
tiingsbus verbunden ist, der beispieisweise aus einem Ka- 
belkasten oder Verzweigungsstiick oder einem AljschluBbe- 
reich in einer der Bereichsvorrichtungen innerhalb eines 
ProzeBsteuer- oder ^regelnetzwerks bestehen kann. 

Es konnen Daten uber die Bussegmente in irgendeiner ei- 
ner Anzahl von unterschiedlichen Kommunikationsbauraten 
Oder Geschwindigkeiten gemaB dem Fieldbus-Protokoll ge- 
sendet werden. Beispieisweise schafft das Fieldbus-Proto- 
koll eine 31,25-Kbit/s-Kommunikationsrate (HI) oder eine 
1,G-Mbits- und/oder eine 2,5-Mbit/s-(H2)-Konmiunikati- 



ein ortliches Bereichsnetzwerk fiir BereichsmeBgerate (Be- 40 onsrate, die in typischer Weise fiir eine fortschrittHche jPiro- 

reichsvorrichtungen) innerhalb eines Prozesses, welches zeBsteuerung oder -regelung, Femeuigabe-Aausgabe und fur 

diese Bereichsvorrichtungen dazu befahigt, Steuerfunktio- Hochgeschwindigkeits-Fabrikautomatisationsanwendurigen 

nen an SteUenauszufiihren, die uber eine ProzeBeinrichtung angewendet werden. In gleicher Weise konnen uber den 

hinweg verteilt sind, und mit einer anderen zu kommunizie- Fieldbus-Bus Daten unter Verwendung einer Spannungs- 

ren, vor und nach der Ausfuhrung dieser Steuerfunktionen, 45 mode-Signalgebung oder einer Strommode-Signalgebung 



urri eine Gesamtsteuer- oder -regelstrategie zu reaHsieren. 
Da das Fieldbus-Protokoll es deri Steuerfunktionen ermog- 
licht, uber ein ProzeBregelnetzwerk hinweg verteilt zu sein, 
reduziert es die Arbbitslast des zentraUsierten ProzeBkour 
trollers fiir diese Bereichsvorrichtungen oder fiir die Berei- 
che des Prozesses. 

Ein Prbzefisteuei:- qder -regelnetzwerk, welches das 
Fieldbus-Protokoll verwendet, kann einen Host enthalten, 
der mit einer Anzahl von anderen Vorrichtungen verbunden 
ist, wie beispieisweise logischen Programmkontrollem, an- 
deren Host vorrichtungen und Bereichsvorrichtungen (field 
• devices) uber eine Zweidraht-Fieldbus-Schleife oder -Bus, 
wie beispieisweise den Bus 42 von Fig. 1. Der Fieldbus-Bus 
kann unterschiedliche Abschnitte oder Segmente enthalten. 
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ubertragen werden. Die maximale Lange von irgendeinem 
Fieldbus-Bus qder -Segment ist nicht strikt begrenzt, son- 
dem wird statt dessen durch die Kommunikationsrate, den 
Kabeltyp, die LeitungsgroBe, Busleistungsoptionen usw. 
festgelegt. 

Das Fieldbus-Protokoll klassifiziert die Vorrichtungen, 
die an den Bus angeschlossen werden konnen, in drei pri- 
mare Kategorien, namhch die Basis vorrichtungen, die Ver- 
bindungsmastervorrichtungen und die Briickenvorrichtun- 
gen. Die Basis vorrichtungen konnen kornmunizieren, das 
heiBt Kommunikation ssignale auf den Bus senden oder von 
diesem empfangen, sind jedoch nicht dazu befahigt, die Rei- 
henfoige oder Zeitsteuerung der Kommunikation zu steuern, 
die auf dem Bus auftreten. Die Verbindungsmastervorrich- 



die durch Bruckenvorrichtungen getrennt sind, wobei jeder 60 tungen bestehen aus Vorrichtungen, die iiber dem Bus kom- 



Abschnitt des Busses einen untergeordneten Satz der Vor 
richtungen verbindet, die an den Bus angebracht sind, um 

Konomunikationen zwischen den Vorrichtungen in einer 
Weise zu ermoglichen, wie sie im folgenden beschrieben 
wird. In typischer Weise ist eine Konfiguriervorrichtung in 
einer der. Vorrichtungen gelegen, wie beispieisweise einem 
Host, und ist fiir die Einrichtung oder Konfigurierung jeder 
der Vorrichtungen verantwortHch (die " Smart" -Vorrichtun- 



munizieren und die Fahigkeit haben, den FluB und die Zeit- 
steuerung der Kommunikationssignale auf den Bus zu steu- 
ern. Die Bruckenvorrichtungen bestehen aus Vorrichtungen, 
die dafiir konfiguriert sind, um mit einzelneii Seginenten 
65 Oder Zweigen eines Fieldbus-Busses zu kommunizieren 
Oder diese einzelnen Segmente oder Zweige miteinander zu 
verbinden, um ein groBere ProzeBsteuer- oder -regelnetz- 
werk zu eizeugen. Wenn es gewunscht wird, k6nnen die 
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Briickenvorrichtungen zwischen unterschiedlichen Daten- 
geschwindigkeiten und/oder. unterschiedlichen Datensigna- 
lisieruogsfonnaten eine Umwandlung vomehmen, die auf 
deh unterschiedlichen Segmenten des Busses verwendet 
werden, konnen Signale vers^ken, die zwischen den Seg- 5 
menten des Busses wandern, konnen die Signale filtem, die 
zwischen unterschiedlichen Segmenten des Busses verlau- ' 
fen, und konnen ledigUch solche Signale durchlassen, die 
dafiir bestimmt sind, durch eine Vorrichtung an einem der 
Bussegmente empfangen zu werden, an welches die Briicke 10 
gekoppelt ist und/oder konnen andere Aktionen vomehmen, 
die eiforderlich sind, um unterschiedliche Segmente des 
Busses zu verbinden. Die Briickenvorrichtungen, welche die 
Bussegmente verbinden, die mit unterschiedlichen Ge- 
schwiridigkeiten arbeiten, mussen Verbindungsmasterfahig- 15 
keiten auf der Seite des Segmentes mit niedrigerer Ge- 
sch windigkeit der Briicke besitzen. 

Jede der Fieldbus-Vorrichtungen besitzt die Fahigkeit, 
iiber den Bus zu kommunizieren, und, was wichtig ist, die 
Fahigkeit unabhangig eine oder mehrere ProzeBsteuerfunk- 20 
tiorien durchzufiihren unter Verwendung von Daten, die 
durch die Vorrichtung von dem ProzeB erworben wurden, 
Oder von einer unterschiedlichen Vorrichtung erworben 
wurdeii, und zwar uber die Kommunikationssignale auf dem 
Bus. Die Fieldbus-Vorrichtungen besitzen dahef die Fahig- 25 
keit, direkt Abschnitte einer Gesamtsteuer- oder -regelstra- 
tegie zu implementieren, die in der Vergangenheit durch ei- 
nen zentrahsierten digitalen Kontroller durchgefuhrt wur- 
den, Um Steuerfunktionen durchzufiihren, enthalt jede 
Fieldbus- Vorrichtung einen oder mehrere standardisierte 30 
"Blocke", die in einem Mikroprozessor innerhalb der Vor- 
richtung implementiert sind. Speziell enthalt jede Fieldbus- 
. Vorrichtung einen Ressourcenblock, Null- oder Mehrfunkti- 
onsblocke und Null- oder Mehrwandlerblocke. Diese 
Blocke werden als Blockobjekte bezeichnet. . 35 

Ein Ressourcenblock speichert und iibertragt spezifische 
Vorrichtungsdaten, die einige Charakteristika einer Field- 
bus- Vorrichtung betreffen, inklusive beispielsweise einem 
Vorrichtungstyp; einer Vorrichtungsrevisionsanzeige und 
Anzeigen daruber, wo andere spezifische Vorrichtungsinfpr- 40 
mationen innerhalb eines Speichers der Vorrichtung erhalten 
werden konnen. Wahrend verschiedene Vorrichtungsher- 
steller unterschiedliche Typen der Daten in dem Ressour- 
cenblock einer Bereichs vorrichtung speichem konnen, ent- 
halt jede Bereichs vorrichtung, die mit dem Fieldbus-Proto- 45 
•koU konform ist, einen Ressourcenblock, der einige Daten 
speichert. 

- Ein Funktionsblock definiert und implementiert eine Ein- . 
gabefiinktioh, eine Ausgabefiinktion oder eine Steuerfunk- 
tion, die der Bereichs vorrichtung zugeordnet ist und es wer- 50 
den somit Funktionsblocke allgemein als Eingabe-, Aus- 
gabe- und Steuerfunktionsblocke bezeichnet, Es konnen je- 
doch andere Kategorien von Funktionsblocken existieren, 
wie beispielsweise Hybrid-Funktionsblocke, oder konnen 
auch in der Zukunft entwickelt werden. Jeder Eingabe- oder 55 
Ausgabefunktiorisblock erzeugt wenigstens eine ProzeB- . 
steuereingangsgrofie (wie beispielsweise eine ProzeBvaria- 
ble aus einer ProzeBmeBvorrichtung) oder eine ProzeBsteu- 
erausgangsgroBe (wie beispielsweise eine Ventilposition, 
die zu einer SteUvorrichtung gesendet, wird), wahrend jeder 60 
Steuerfunktionsblock einen Algorithmus verwendet (der in 
seiner Natur geschiitzt oder firmeneigen sein kann), um eine 
oder mehrere ProzeBausgangsgroBen aus einer oder aus 
mehreren ProzeBeingangsgroBen und aus Steuereingangs- 
groBen zu erzeugen. Beispiele vori Standardfunktionsblok- 65 
ken umfassen Analogeingangs(Al)-, Analogausgangs(AO)- 
, Vorspann(B)-, Steuerwahi(CS)-, Diskreteingangs(DI)-, • 
Diskretausgangs(DO)-, Handlade(ML)-, Proportional/Dif- 



ferential(PD)-, Proportional/EntegraVDifferentialCPDI)-, 
Verhaltms(RA)- und Signalwahl(SS)-FunktionsblockeJ IBs 
existieren jedoch andere lypen von Funktionsblocken und 
neue Typen von Funktionsblocken konnen festgelegt oder 
hergestellt werden, um in der Fieldbus-Unigebung zu arbei- 
ten. 

Ein Wandlerblock koppelt die EingangsgroBen und Aus- 
gangsgroBen eines Funktiohsblockes an die ortlichen Hard- 
warevorrichtungen, wie beispielsweise an Sensoren und 
Vorrichtungsstellglieder, um die Funktionsblocke dazu zu 
befahigen, die AusgangsgroBen von ortlichen Sensoren zu 
lesen iind die ortlichen Vorrichtungen mit Befehlen zu ver- 
sehen, um eine oder mehrere Funktionien, wie beispiels- 
weise das Bewegen eines Ventilteiles auszufuhren. Wandler- 
blocke enthalten.in typischer Weise Informationen, die er- 
forderlich sind, um Signale zu interpretieren, die durch eine 
brtliche Vorrichtung abgeleitet wurden, und um in richdger 
Weise die ortlichen Hardwarevorrichtungen zu steuem, wo- 
bei diese Informationen beispielsweise Information enthal- 
ten, die den Typ einer ortlichen Vorrichtung identifizieren, 
Eichungsinformationen, die einer ortlichen Vorrichtung zu- 
geordnet sind, betreffen usw. Ein einzelner Wandlerblock ist 
in typischer Weise jedem Eingabe- oder Ausgabefiinktion s- 
block zugeordnet. 

Die meisten Funktionsblocke sind dazu befahigt. Alarm 
oder Ereignisanzeigen zu generieren, basierend auf vorbe- 
stimmten Kriterien, und haben die Fahigkeit unterschiedlich 
in verschiedenen Modi zu arbeiten. Allgemein gesagt, kon- 
nen Funktionsblocke in einem automatischen Modus arbei- 
ten, in welchem beispielsweise der Algorithmus eines Funk- 
tionsblockes automatisch ait>eitet; in einem Operatormodus 
arbeiten, in welchem der Eingang oder der Ausgang eines 
Funktionsblockes von Hand gesteuert wird; einem AuBer- 
Servicemodus arbeiten, in welche der Block nicht arbeitet; 
in einem Kaskadenmodus arbeiten, in welchem die Opera- 
tion des Blockes von der AusgabegroBe eines verschiedenen 
Blockes beeinfiuBt wird (durch diesen bestimmt wird); und 
in einem oder mehreren Entfernungsmodi- arbeiten, in wel- 
chen ' ein entfemt gelegener Computer den ^ Modus des 
Blocks bestimmt. Es existieren jedoch in dem Fieldbus-Pro- 
tokoll andere Betriebsmodi. 

Als wichtiges Merkmal besitzt jeder Block die Fahigkeit, 
mit anderen Blocken in der gleichen oder unterschiedlicHen 
Bereichs vorrichtungen iiber den Fieldbus-Bus zu kommuni- 
zieren, und zwar unter Verwendung von Standardnachrich- 
tenformateri, die durch das Fieldbus-Protokpll festgelegt 
sind. Als ein Ergebnis konnen Kombinationen von Funk- 
tionsblocken (in den gleichen oder unterschiedlichen Vor- 
richtungen) miteinander kommunizieren, um eine oder meh- . 
rere dezentralisierte Regelschleifen zu erzeugen. Es kann 
somit beispielsweise ein PID-Funktionsblock in einer Be- 
reichsvorricHtung iiber den Fieldbus-Bus angeschlossen 
sein, um eine AusgangsgroBe eines AI-Funktionsblocks in 
einer zweiten Bereichs vorrichtung zu empfangen, um Daten 
an einen AO-Funktionsblock in einer dritten- Bereichs vt)r- 
richtung zu liefem, um eine. AusgangsgroBe eines AO- 
Funktipnsblocks .als RiickkopplungsgroBe zu empfangen, 
um eine ProzeBregelschleife getrennt und neben irgendei- 
nem zentraHsierten Kontroller zu erzeugen. Auf diese Weise 
bewegen -Kombinationen vori Funktionsblocken die Steuer- 
funktionen aus einer zentraHsierten DCS-Umgebung heraus, 
was die Moglichkeit schaift, daB DCS-Vielfunktionskon- 
troller Uberwachungs- oder Koordinationsfunktionen 
durchfiihren. Femer erlauben es die Funktionsblocke, eine 
graphische blockorientierte Struktur zu verwenden, und 
zwar eine einfache Konfiguration eines Prozesses, und er- 
moglicheri die Verteilung der Funktionen unter den Be- 
reichsvorrichtungen von unterschiedlichen ^ulieferem, da 
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diese Blocke ein konsistentes Kommunikationsprotokoll 
verwenden. 

Zusatzlich zu dem Merkmal, daB Bereichsvorrichtungen 
Blockobjekte enthalten und implementieren, enthalt jede 
Bereichsvorrichtung ein oder mehrere andere Objekte, in- 
klusive Verbindungsobjekten, Trendobjekten, Wamobjekten 
und Betrachtungsobjekten. Verbindungsobjekte definieren 
die Verbindungen zwischen den Eingangen und Ausgangen 
der Blocke (wie den Funktionsblocken), und zwar sowohl 
intern in der Bereichsvorrichtung als auch uber den Field- 
bus-Bus hinweg. Trendobjekte erlauben einen ortlichen 
- Trend von Funktionsblockparametem fiir den Zugriff auf 
andere Vorrichtungen, wie beispielsweise einen Host oder 
einen Kontroller. Trendobjekte halten historische Kurzzeit- 
daten, die einige, beispielsweise den Funktionsblockpara- 
meter, betreffen und berichten diese Daten an andere Vor- 
richtungen Oder Funktionsblocke, und zwar uber den Field- 
bus-Bus in einer asynchronen Weise. Wamobjekte berichten 
iiber Alarme und Ereignisse uber den Fieldbus-Bus. Diese 
Alarme oder Ereignisse konnen irgendein Ereignis betref- 
fen, welches innerhalb einer Vorrichtung stattfindet oder in- 
• "rierhalb einem der Blocke einer Vorrichtung. Betrachtungs- 
objekte sind vordefinierte Gruppierungen von Blockpara- 
metem, die in standardisierten Mensch/Maschine-Schnitt- 
stellenbereichen verwendet werden und die zu anderen Vor- 
richtungen gesendet werden konhen, und zwar unter Ver- 
wendung von asynchronen Ubertragungen, um eine Be- 
trachtung von Zeit zu Zeit zu ermog:lichen. 

In Fig, 2 sind drei Fieldbus- Vorrichtungen veranschau- 
licht, die beispielsweise aus irgendeiner der Bereichsvor- 
richtungen 43-50 von Fig, 1 bestehen, und diese enthalten 
Ressourcenblocke 58, Funktionsblocke 60, 61 oder 62 und 
Wandlerblocke 63 und 64. In der ersten Vorrichtung ist der 
Funktionsblock 60 (der aus einem Eingabefunktionsblock 
besteht) uber den Wandlerblock 63 mit einem Sensor 65 ge- 
koppelt, der beispielsweise aus einem Temperatursensor, ei- 
nem Sollpunktanzeigesensor usw. bestehen kann. In der 
zweiten Vorrichtung ist der Funktionsblock 61 (der aus ei- 
nem Ausgabefiinktionsblock bestehen kann) uber den 
Wandlerblock 64 an eine Ausgabevorrichtung, wie bei- 
spielsweise ein Ventil 66, gekoppelt. In der dritten Vomch- 
tung enthalt der Funktionsblock 62 (der aus einem Steuer- 
funktionsblock bestehen kann) ein Trendobjekt 67, welches 
diesem zugeordnet ist, um den Trend, des Eingangsparame- 
ters des Funktionsblocks 62 zu ermittehi. 

Die Verbindungsobjekte 68 definieren die Verbindungen 
von Blockparametem yon jedem der zugeordneten Blocke 
und die Wamobjekte 69 erzeugen Alarme oder Ereignisbe- 
nachrichtigungen fur jeden der zugeordneten Blocke. Be- 
trachtungsobjekte 70 sind mit jedem der Funktionsblocke 
60, 61 und 62 zugeordnet und enthalten 'Gruppendatenlisten 
fiir die Funktionsblocke, zu denen sie zugeordnet sind. 
Diese Listen enthalten Informationen, die fiir jeden eines 
Satzes von unterschiedlich definierten Betrachtungen erfor- 
derhch sind. Natlirlich steUen die Vorrichtungen von Fig, 2 
lediglich Beispiele dar und andere Zahlen und TVpen von 
Blockobjekten, Verbindungsobjekten, Wamobjekten, 
Trendobjekten und Betrachtungsobjekten konnen in irgend- 
einer Bereichsvorrichtung vorgesehen sein. 

Um eine Kommunikation und Steueraktivitaten zu imple- 
mentieren und auszufiihren, verwendet das Fieldbus-Proto- 
koll drei alLgemeine Kategorien der Technologic, die als 
eine physikalische Schicht, als ein Kommunikations-"Sta- 
pel" lind eine Anwenderschicht definiert sind. Die Anwen- 
* derschicht enthalt die Steuer- und Konfigurationsfunktio- 
nen, die in Form der Blocke voigesehen werden (wie bei- 
spielsweise den Funktionsblocken) und Objekte innerhalb 
irgendeiner bestimmten ProzeBsteiiervorrichtung oder Be- 
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reichsvorrichtung. Die Anwenderschicht ist in typischer 
Weise in einer geschutzten Weise ausgelegt oder konstruiert, 
und zwar durch den Hersteller der Vorrichtung, muB jedoch 
die Fahigkeit haben, Nachrichten zu empfangen und auszu- 
5 senden, und zwar in Einklang mit dem Standardnachrichten- 
format, welches durch das Fieldbus-ProtokoU festgelegt ist, 
und mu6 durch einen Anwender in der standardisierten 
Weise konfigurierbar sein. Die physikalische Schicht und 
der Kommunikationsstapel sind erforderlich, um eine Nach- 
10 richtenverbindung zwischen unterschiedlichen Blocken un- 
terschiedlicher Feld- oder Bereichsvorrichtungen in einer 
standardisierten Weise zu bewirken, und zwar unter Ver- 
wendung eines Zweidrahtbusses, und konnen durch das gut 
bekaiinte Open-Systems-Interconnect-(OSI)-Schicht-Kom- 
15 munikationsmodell modeHiert sein. 

Die physikalische Schicht, die der OSI-Schicht 1 ent- 
spricht, ist in jeder Bereichsvorrichtung und in dem Bus ein- 
gebettet und arbeitet dahingehend, um elektromagnetische 
Signale, die von dem Fieldbus-Ubertragungsmedium (dem 
20 Fieldbus-Zweidrahtbus) empfangen werden, in Nachrichten 
: umzusetzen, die durch den Konmiunikationsstapel der Be- 
reichsvorrichtung verwendet werden konnen. Die physikali- 
sche Schicht kann als ein Fieldbus-Bus und elektromagneti- 
schen Signalen,,die auf dem Bus an den Eingangen und Aus- 
25 gangen der Bereichsvorrichtungen vorhanden sind, betrach- 
tet werden. 

^ Der Kommunikationsstapel, der in jeder Fieldbus-Vor- 
richtung vorhanden ist, enthalt eine Datenverbindungs- 
schicht, die der OSI-Schicht 2 entspricht, eine Fieldbus-Zu- 
30 griffs-Sub-Schicht und eine Fieldbus-Nachricht-Spezifikati- 
onsschicht Die Anwenderschicht des Fieldbus-ProtokoUs 
besteht aus einer Schicht, die in dem OSI-Protokoll nicht de- 
finiert ist. Jede Schicht in dem Kommunikationsstapel ist fur 
die Kodiemng und Dekodiemng eines Abschnitts der Nach- 
35 richt Oder des Signals verantwortlich, welches uber den 
Fieldbus-Bus iibertragen wird. Als ein Ergebnis addiert oder 
entfemt jede Schicht des Konununikationsstapels gewisse 
Abschnitte des Fieldbus-Signals, wie beispielsweise die 
Praambeki, Startbegrenzer und Endebegrenzer, und in eini- 
40 gen Fallen, dekodiert sie Bandabschnitte des Fieldbus-Si- 
gnals, um eine Idehtifizierung dariiber durchzufiihren, ob 
der Rest des Signals oder der Nachricht gesendet werden 
sollte Oder ob das Signal geloscht werden sollte, da.es bei- 
spielsweise eine Nachricht oder Daten fur Funktionsblocke 
45 enthalt, die nicht innerhalb der empfangenden Bereichsvor- 
richtung vorhanden sind. 

Die Datenverbindungsschicht steuert die Ubertragung 
von Nachrichten auf dem Fieldbus-Bus und managt den Zu- 
griff auf den Bus gemaB einer deterministischen.zentrali- 
50 sierten Busablaufsteuerung (scheduler), der als ein verbin- 
dungsaktiver Abwickler bezeichnet wird, der im folgenden 
, noch mehr in Einzelheiten beschrieben wird. Die Datenver- 
bindungsschicht entfemt eine Praambel von den Signalen 
auf dem tfbertragungsmedium und kann die empfangene 
55 Praambel verwenden, um den intemen Takt der Bereichs- 
vorrichtung mit dem ankommenden Fieldbus-Signal zu syn- 
chronisieren. In ahnlicher Weise wandelt die Datenverbin- 
dungsschicht die Nachrichten auf dem Kommunikationssta- 
pel in physikalische Fieldbus- Signale um und kodiert diese 
60 Signale mit der Taktinformatipn, lun ein "synchrones seriel- 
les" Signal mit einer richtigen Praambel fiir die Ubertragung 
auf dem Zweidrahtbus oder -schleife zu erzeugen. Wahrend 
des Dekodierungsprozesses erkennt. die Datenverbindungs- 
schicht spezifische Kodes innerhalb der Praambel, wie bei- 
65 spielsweise Startbegrenzer und Endebegrenzer, um den An- 
fang und das Ende einer bestimmten Fieldbus-Nachricht zu ' 
identifizieren, und kann eine Priifsumme erstelien, um die 
Integritat des Signals oder der Nachricht, die von dem Bus 
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empfangen wurde, zii verifizieren. In ahnlicher Weise iiber- 
tragt die Datenverbindungsschicht die Fieldbus-Signale auf . ^ 
den Bus, indem sie Start- und Endebegrenzer zu den Nach- 
ricbten auf dem Datenkommunikationsstapel hinzufugt und 
indem sie diese Sighale auf das Ubertragungsmedium zu ei- 5 
ner geeigneten Zeit setzt' 

Die Fieldbus-Nachrichten-Spezifikationsschicht erlaubt 
es der Anwenderschicht (das heifit den Funktionsblocken, 
Objekten usw. einer Bereichsvorrichtung), iiber den Bus zu 
kommunizieren, und zwar unter Verwendung eines Stan- 10 
dardsatzes von Nachrichtenformaten und beschreibt den 
Konununikationsservice, die Nachrichtenformate und die 
Protokollverhaltensweisen, die erforderlich sind, um Nach- 
richten herzustellen, die auf den Konununikationsstapel zu • 
setzeh sind und die fiir die Anwenderschicht vorzusehen- 15 
sind. Da die Fieldbus-Nachrichteh-Spezifikationsschicht 
standardisierte Kommunikationen fiir die Anwenderschicht 
liefert, sind spezifische Fieldbus-Nachrichten-Spezifikati- 
ons-Kommunikationsdienste fiir jeden lyp des oben be- 
schriebenen Objekts festgelegt. Bei spiels weise enthalt die 20 
Fieldbus-Nachrichten-Spezifikationsschicht Objektwortef- 
buchdienste, die es dem Anwender ermoglichen, in einem 
Objektwortorbuch einer Vorrichtuhg zu lesen. Das Objekt- 
worterbuch speichert Objektbeschreibungen, welche jedes 
der Objekte beschreiben oder identifizieren (wie beispiels- 25 
weise Blockobjekte), und zwar von einer Vorrichtung. Die 
Fieldbus-Nachriehten-Spezifikationsschicht ermoglicht 
auch variable Zugriffsdienste, die es einem Anwender er- 
moglichen, Kommunikationsbeziehungen, die als virtuelle 
Komniunikationsbeziehungen (VCRs) bekannt sind und im 30 
folgenden beschrieben werden, die einer oder mehreren Ob- 
jekten' einer Vorrichtung zugeordnet sind, zu lesen und zu 
andem. Dariiber hinaus schafft die Fieldbus-Nachrichten- 
Spezifikationsschicht ein Kontextmanagement, variable Zu- 
griffsdienste, Ereignisdienste, Hochlade- und Herunterlade- 35 
dienste und Programmaufrufdienste, die alle in Verbindung 
mit dem Fieldbus-ProtokoU gut bekannt sind und daher hier 
nicht in EinzeUieiten beschrieben werden. Die Fieldbus-Zu- 
griffs-Sub-Schicht bildet die Fieldbus-Nachrichten-Spezifi- 
kationsschicht in der Datenverbindungsschicht ab. 40 

Urn einen Betrieb dieser Schichten zuzulassen oder zu er- 
moglichen, enthalt jede Fieldbus- Vorrichtung eine Manage- 
mentinformationsbasis (MIB), die aus einer Datenbasis oder 
Datenbank besteht, die VCRs, dynamische Variable, statisti- 
"sche GroBen, Zeitsteuerplane, Funktionsblockausfuhrungs- 45 
zeitsteuerplane und eine \ferrichtungsetikette (device tag) 
und Adresseninformationen speichert. Natiirlich konnen die 
Informationen innerhalb der MIB zugegriffen werden oder .. 
zu iigendeiner Zeit unter Verwendung der Standard-Field- 
bus-Nachrichten oder -Befehle geandert werden. Femer ist 50 
gewohnlich eine Vorrichtungsbeschreibung fiir jede Vor- 
richtung vorgesehen, um einem Anwender oder einem Host 
einen weiten Uberbhck an Informationen in der VFD zu ge- 
ben. Eine Vorrichtungsbeschreibung, die in typischer Weise 
in Form einer Sendeerlaubnis, um von einem Host verwen- 55 
del zu werden, festgelegt ist, speichert Informationen, die 
fur den Host^rforderlich sind, um die Bedeutung def Daten 
in den VFDs einer Vorrichtung zii verstehen. 

Wie ersehen werden kann, muB die Implementierung von 
irgendeiner Steuerstrategie unter Verwendung der Funk- 60 
tionsblocke, die uber ein ProzeBregelnetzwerk verteilt ange- 
ordnet sind, die Ausfiihrung der Funktionsblocke prazise 
geplant werden, und zwar in bezug auf die Ausfiihrung von 
anderen Funktionsblocken in einer bestimmten Regel- 
schleife. In ahnUcher Weise mu6 die Kommunikation zwi- 65 
schen'unterschiedlichen Funktionsblocken in praziser Weise 
auf dem Bus geplant werden, so daB die richtigen Daten zu 
jedem Funktionsblock iibertragen werden, bevor dieser 
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Block ein Programm ausfiihrt. 

Der Weg, mit welchem unterschiedliche Bereichsvorrich- 
tungen (und unterschiedliche Blocke innerhalb den Be- 
reichsvorrichtungen) iiber das Fieldbus-Ubertragungsme- 
dium kommunizieren, soil nun beschrieben werden. Damit 
eine Kommunikation stattj&ndet, arbeitet eine der Verbin- 
dungsmastervorrichtungen auf jedem Segment der Field- 
bus-Schleife als ein verbindungsaktiver Abwickler (LAS), 
der aktiv die Kommunikation auf dem zugeordneten Seg- 
ment des Busses abwickelt und steuert. Das LAS fiir jedes 
Segment des Busses speichert einen Kbmmunikationsplan 
(einen verbindungsaktiven Plan), der Zeitpunkte enthalt, bei 
denen jeder Funktionsblock von jeder Vorrichtung geplant 
ist, periodisch die Kommunikationsaktivitat auf dem Bus zu 
starten und auch die Lange der Zeit geplant ist, wahrend. 
welcher diese Kommunikationsaktivitat stattfinden muB. 
Wahrend lediglich eine und nur eine aktive LAS- Vorrich- 
tung auf jedem Segment des Busses vorhanden sein kann, 
konnen andere Verbindungsmastervorrichtungen als Bak- 
kup-LASs dienen und konnen beispiels weise dann aktiv 
werden, wenn die momentane LAS ausfallt. Die Basis vor- 
richtungen haben nicht die Fahigkeit, eine LAS zu iigendei- 
nem Zeitpunkt zu werden. 

Allgemein gesagt, werden die KonMnunikationsaktivita- 
ten uber den Bus eingeteilt in Wiederholungsmakrozyklen, 
die den synchronen Konmiunikationsplan fiir den Bus defi- 
nieren. Eine Vorrichtung kann aktiv sein, das heiBt Daten zu 
irgendeinem Segment des Busses senden oder von diesem 
empfangen, und zwar selbst wenn sie physikalisch an ein 
unterschiedliches Segment des Busses angeschlossen ist, 
und zwar durch eine koordiniefte Operation der Briicken 
und der LASs auf dem Bus. 

Wahrend jedes Makrozyklusses fiihrt jeder - der Funk- 
tionsblocke, die auf einem bestimmten Segment des Busses 
aktiv sind, gewohnlich zu einem unterschiedlichen, jedoch 
prazise geplanten (synchronen) Zeitpunkt oder Zeit ein Pro- 
gramm durch. Wenn der Funktionsblock einen Ausgangspa- 
rameter hat, der mit einem anderen Parameter extern zu der 
Vorrichtung verkettet ist, so veroffenthcht der Funktions- 
block seine Ausgangsdaten in einer prazise geplanten Zeit 
im Ansprechen auf einen Erzwingungsdatenbefehl, der 
durch die LAS erzeugt wurde. In bevorzugter Weise ist jeder 
Funktionsblock so eingeplant, daB er seine Ausgabedateh • 
kurz nach dem Ende der Ausfiihrungsperiode des Funk-, 
tionsblockes verofFentlicht. Femer sind die Datenveroffent- 
lichungszeitpunkte der verschiedenen Funktionsblocke in., 
serieller Form geplant oder einer Ablaufsteuerung unterwor- 
feri, so daB keine zwei Funktionsblocke auf einem bestimm- . 
ten Segment des Busses Daten zur gleichen Zeit veroffentli- 
cheii. Wahrend der Zeit, wahirend welcher eine synchrone 
Kommunikation nicht stattfindet, hat jede Bereichsvorrich- 
tung die Moglichkeit, ihrerseits Alarmdaten, Betrachtungs- 
daten usw. in einer asyrichronen Weise zu senden, und zwar 
unter Verwendung von sendeanfrage-angetriebenen Kom- 
munikationen. Der Ausfiihrungs- oder Ablaufplan ist in ei- 
ner Mangementinformationsbasis (MIB) abgespeichert, es 
sind die Ausfuhrungszeitpunkte der Blocke in den Funk- 
tionsblocken gespeichert und es sind die Zeitpunkte zum 
Senden der Zwangsdatenbefehle zu jeder der Vorrichtungen 
auf einem Segment des Busses in der MEB der LAS- Vorrich- 
tung fiir. dieses Segment gespeichert. Diese Zeitpunkte wer- 
den in typischer Weise als Offsetzeiten gespeichert, da sie 
die Zeiten oder Zeitpunkte identifizieren, zu welchen Funk- 
tionsblock ein Programm ausfiihren oder Daten senden 
muB, und zwar in einer Versetzung (Offset) vom Anfang ei- 
ner "absoluten Verbindungsplanstartzeit", die alien Vorrich- 
tungen, die an den Bus angeschlossen sind, bekannt ist. 

Um Kommunikationen zwischen jedem Makrozyklus zu 
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bewirken, sendet die LAS einen Zwangsdatenbefehl zu je- 
der der Voirithtungen auf dem zugeordneten Bussegment 
gemaB der Liste der Sendezdtpunkte, die in dem verbin- 
dungsaktiven Plan gespeichert sind. Nach dem Empfang ei- 
nes Zwangsdatenbefehls veroffentlicht ein Funktionsblock 
einer Vorrichtung seine Ausgabedaten auf dem Bus. Da je- 
der der Funktionsblocke typischerweise einer Ablaufsteue- 
rung unterliegt, um ein Programm aus zufuhren, so daB die 
Ausfuhrung des Programms dieses Blocks vervollstandigt 
wird, kurz bevor der Block im Plan dafiir vorgesehen ist, ei- 
nen Zwangsdatenbefehl zu empfangen, sollten die Daten, 
die im Ansprechen auf einen Zwangsdatenbefehl veroffent- 
licht werden, die allerletzten Ausgangsdaten des Funktions- 
blockes sein. Wenn jedoch ein Funktionsblock in der Pro- 
grammausfuhrung langsam ist und keine neuen Ausgangs- 
groBen verriegelt hat, wenn er den Zwangsdatenbefehl emp- 
fangt, veroffentlicht der Funktionsblock die Ausgangsdaten, 
die wahrend des letzten Laufes des Funktionsblockes er- 
zeugt wurden. 

Wahrend der Perioden, in welchen die Zwangsdatenver- 
offentlichungen nicht geplant sind, kann die LAS asyn- 
chrone Kommunikationsaktivitaten aktivieren. Um eine 
asynchrone Kommunikation zu bewirken, sendet die LAS 
eine DurchlaB-Token-Nachricht zu einer bestimmten Be- 
reichsvorrichtung, Wenn eine Bereichsvorrichtung eine 
DurchlaB-Token-Nachricht empfangt, erlangt diese Be- 
reichsvorrichtung voUen Zugriff auf den Bus (oder ein Seg- 
ment desselben) und kann asynchron Nachrichten senden, 
wie ,beispielsweise Alannnachrichten, Trenddaten, Opera- 
tor-Sollpunktanderungen usw., bis die Nachrichten vervoll- 
standigt sind Oder bis eine maximal zugewiesene "Token- 
Haltezeit" verstrichen ist. Danach gibt die Feld vorrichtung 
den Bus frei (oder rirgendein bestimmtes Segment dessel- 
ben) und die LAS sendet eine DurchlaB-Token-Nachricht zu 
•einer anderen Vorrichtung. Dieser ProzeB wird wiederholt, 
bis "die LAS entweder gemaB dem Plan einen Zwangsdaten- 
befehl aussendet, lim eine synchrone Kommunikation zu be- 
wirken, Oder die LAS eine Netzwerkwartung durchzufiihren 
hat. Natiirlich kann abhangig vom AusmaB des Nachrich- 
teiiverkehrs und der Zahl der Vorrichtung und der Blocke, 
die an ein bestimmtes Segment des Busses gekoppelt sind, 
■ nicht jede Vorrichtung eine DurchlaB-Token-Nachricht wah- 
rend jedes Makrozyklus.ses empfangen. 

Fig, 3 veranschauhcht ein Zeitsteuerschema, welches die 
Zeitpunkte herausgreift, bei den die Funktionsblocke (mit 
ALloopi, PIDloopi,. AIloop2, AOloopi, SSloop2 "nd PID- 
LOOP3) eiri Programm ausfiihren, und. zwar wahrend jedes 
Makrozyklusses eines Bussegmentes, und die Zeitpunkte, 
bei denen eine synchrone Kommunikation wahrend jedes 
Makrozyklusses stattfindet, der dem Bussegment zugeord- 
net ist. In dem Zeitsteuerplan von Fig, 3 ist die Zeit auf der 
-• horizontalen Achse aufgetragen und die Aktivitaten, die den 
unterschiedhchen Funktionsblocken zugeordnet sind, sind 
auf der vertikalen Achse v^anschaulicht. Die Regelschleife 
(die zum Zwecke der Erlauterung wiUkiirhch ist), in welcher 
jeder der Funktionsblocke arbeitet, ist in Fig. 3 als Iridexari- 
gabe identifiziert. Somit verweist AIloopi auf den AI-Funk- 
tionsblock von bei spiels weise einem Sender, der innerhalb 
, einer ersten Regelschleife arbeitet, PIDloopi verweist auf 
den PID-Funktionsblock in beispielsweise einem Stellwerk/ 
Ventil, welches innerhalb der ersten Regelschleife arbeitet, 
usw. Die Biockausfuhrungsperiode von jedem der veran- 
schaulichten Funktionsblocke ist durch ein kreuzstrichher- 
tes/Kastchen herausgestellt, wahrend jede geplante syn- 
chrone komriumikation durch einen vertikalen Balken in 
Fig, 3 identifiziert ist. 

Somit fuhrt gemaB dem Zeitsteuerplan von Fig. 3 wah- 
rend irgendeines bestimmten Makrozyklusses des Busseg- 
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merits der AlLoopi-Funktionsblock zuerst ein Programm 
aus, und zwar fiir die Zeitperiode, die durch das Kastchen 71 
spezifiziert ist. Daim, wahrend der Zeitperiode, die durch 
den vertikalen Balken 72 angezeigt ist, wird die Ausgangs- 
5 groBe des AlLOOPi-F^riktionsblockes auf dem Bussegment 
im Ansprechen auf einen Zwangsdatenbefehl von der LAS 
fiir das Bussegment veroffentlicht. In ahnlicher Weise zei- 
gen die Kastchen 74, 76, 78, 80 und 80 die Ausfiihrungszei- 
ten der jeweiligen Funktionsblocke PIDloopi » AIlqopi, AO- 
10 LOOPi, SSloop2 und PIDloops, die fiir jeden der unterschied- 
hchen Blocke verschieden sind, an, wahrend die vertikalen 
■ Balken 82, 84, 86, 88 und 89 die Zeiten anzeigen, zu wel- . 
chen die jeweiligen Funktionsblocke PIDLooPb AlLd0P2i 
AOloopi, SSloop2 und PEDloops Daten auf dem Busseg- 
15 ment veroffentiichen. 

Wie zu erkennen ist, veranschaulicht das Zeitsteuer-' 
schema von Fig, 3 auch die Zeitpunkte oder Zeiten, die fur 
asynchrone Kommunikationsaktivitaten verfiigbar sind, die 
wahrend der Ausfiihrungszeiten von irgendeinem der Funk- 
20 tionsblocke auftreten konnen und wahrend der Zeit am Ende 
des Makrozyklusses, wahrend welcher keiner der Funk- 
tionsblocke ein Programm ausfuhrt und wenn keine syn- 
chrone Kommunikation auf dem Bussegment stattfindet. ' 
Wenn es natiirUch gewunscht wird, konnen unterschiedliche 
25 Funktionsblocke beabsichtigt so eingeplant werden,*daB sie 
ein Programm zur gleichen Zeit aiisfuhren und daB nicht alle 
Funktionsblocke Daten auf dem Bus veroiffentlichen mus- 
sen, wenn beispielsweise keine andere Vorrichtung an den 
Datenteil hat, die durch einen Funktionsblock erzeugt wer- 
30 den. 

Bereichsvorrichtungen konnen Daten veroffenthchen 
oder iibertragen und konnen Nachrichten iiber den Fieldbus- 
Bus ubertrageri, und zwar unter Verwendung von einer der 
drei virtuelLen Kommunikationsbeziehungen (VCRs), die in. 
35 der Fieldbus-Zugrififs-Sub-Schicht des Stapels yon jeder Be- 
reichsvorrichtung definiert sind. Ein Client/Server- VCR 
wird fiir in eine Warteschlange eingereihte, nicht geplante, 
vom Anwender initialisierte Eins-zu-Eins-Kommunikatio- 
nen 'zwischen den Vorrichtungen auf dem Bus verwendet. 
40 Solche in eine Warteschlange eingereihten Nachrichten wer- 
den in der Reihenfolge gesendet und empfangen, wie sie fiir 
die Aussendung geliefert werden, und zwar geriiaB deren 
Prioritat, ohne daB dabei friihere Nachrichten uberschrieben 
werden. Somit kann eine Bereichsvorrichtung einen Client/ 
45 Server- VCR verwenden, wenn sie eine DurchlaB-Token- 
Nachricht von einem LAS empfangt, um eine Anfragenach- 
richt zu einer anderen Vorrichtung auf dem Fieldbus-Bus zu 
senden. Der Anfrager wird als "Client" bezeichnet und die 
. Vorrichtung^ die die Anfirage empfaiigt, wird als "Server" 
50 bezeichnet. Der Server sendet eine Antwort, wenn er eine 
Durchgangs-Token-Nachricht von dem LAS empfangt. Der 
Client/Server- VCR wird beispielsweise dazu verwendet, uni 
operator-initialisierte Anfragen, wie beispielsweise Sbll- 
punktanderungen, Abstimmparameter, Zugriff und Ande- 
55 rungen, Alarmbestatigungen und Vorrichtungs-up und - 
downloads zu bewirken. 

Ein Reportverteiler VCR wird fiir die in eine Warte- 
schlange eingereiht, nicht geplanten, anwenderinitialisierten 
Kommunikationen von einer bis mehreren Kommunikatio- 
60 nen verwendet. Wenn beispielsweise eine Bereichsvorrich- 
tung mit einem Ereignis- oder einem Trendreport ein Durch- 
gangs-Token von einer LAS empfangt, so sendet diese Be- 
reichsvorrichtung ihre Nachricht zu. einer "Gruppen- 
adresse", die in der Fieldbus-Zugriffs-Sub-Schicht des 
65 Kommunikationsstapels dieser Vorrichtung definiert ist. Die 
Vorrichtungen, die dafur konfigiiriert sind, um auf dieses 
VCR zu horchen, werden den Report empfangen. Der Re- 
portverteilungs-VCR-iyp wird in typischer Weise durch die 
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Fieldbus-Vorrichtungen verwendet, um Alannbenachrichti- 
gungen zu Bedienungskonsolen zu senden. 

Ein Herausgeber/Benutzer-VCR-Typ wird dazu verwen- 
det, uin eine bis viele Kommunikadonen zu puffern. Die ge- 
pufiferten Kommunikationen sind solche, die ledigHch die 
spateste Version der Daten speichem und senden und es 
iiberschreiben daher neue Daten voUstandig die friiheren 
Daten. Die FunktionsausgangsgroBen umfassen beispiels- 
weise gepufiferte Daten. Eine "Veroffentlicher"-Bereichs- 
vorxichtung veroffentlicht oder sendet eine Nachricht unter 
Venvendung des Veroffentlicher/Benutzer-VCR-iyps an 
alle die "Benutzer"-Bereichs-vomchtungen an den Field- 
bus-Bus, wenn die VeroJffentlichervoirichtung eineZwangs- 
datennachricht von der LAS oder von einer Benutzer- oder 
Teilnehmervorrichtung emp^gt. Die Veroffentlicher-/Be- 
nutzerbeziehungen sind vorbestimmt und sind innerhalb der 
Fieldbus-Zugriffs-Sub-Schicht des Kommunikationsstapels 
von jeder Bereichsvorrichtung definiert und gespeichert. 

Um richtige Kommunikationsaktivitaten iiber den Field- 
bus-Bus sicherzustellen, sendet jede LAS periodisch eine 
'Zeitverteilungsnachricht an alle Bereichsvorrichtungen, die 
an ein Segment des Busses angeschlossen sind, was des den 
empfangenden Vorrichtungen ermoglicht, ihre ortUche Da- 
tenyerbindungszeit so einzustellen, daB sie miteinander syn- 
chronisiert sind. Zwischen diesen Synchronisationsnach- 
' richten wird die Taktzeit unabhangig in jeder Vorrichtung 
beibehalten, und zwar basierend auf deren eigenem inter- 
nem Takt. Eine Taktsynchronisation erlaubt es den Be- 
reichsvorrichtungen, die Funktionsblock-Programmausfiih- 
rung mit dem Netzwerk zu synchronisieren. 

Wic aus der oben gegebenen Erlauterung des Fieldbus- 
Kommunikationsprotokolls hervorgeht, erfordert eine Kom- 
munikation mit irgendeiner speziellen Vorrichtung oder ei- 
nem Funktionsblock, der innerhalb des Fieldbus-Abschnitts 
des ProzeBregelnetzwerks 10 gelegen ist, das heiBt an den 
Bus 42 angeschlossen ist, detailliertes Wissen dariiber, auf 
welche Weise die Kommunikation innerhalb des Fieldbus- 
ProtokoUs im allgemeirien bewirkt wird, als auch eine Be- 
trachtung dariiber und ein Wissen davon, wie der Fieldbus- 
Bus' 42 speziell aufgebaut ist und wann Konununikationen, 
die diesem zugeordnet sind, geplant sind und erlaubt wer- 
den. Dies macht es seinerseits fur den Designer der ProzeB- 
regelroutine schwierig, die in dem KontroUer 12 implemen- 
tiert ist, Kommunikationen mit den Vorrichtungen innerhalb 
des Fieldbus-Abschnitts des ProzeBregelnetzwerks zu im- 
plementieren und zu planen, das heiBt den Vorrichtungen, 
die an den Bus 42 angeschlossen sind. Da dariiber hinaus 
Standard- oder regular© Kommunikationen zwischen. den 
Funktionsblocken in einer synchronen Weise iiber den Bus 
42 erfolgen, muB der KontroUer 12 so konfiguriert sein, um 
all diese Kornmunikationen oder Nachrichten oder wenig- 
stens die einen zu empfangen, die er zur Ausfiahrung der 
Steuer- oder Regelroutihe benotigt. Es kann eine entmuti- 
gende Aufgabe auf Seiten des KontroUers 12 werden, den 
Empfang und die Speicherung von all den Informationen zu 
koordinieren, die auf dem Bus 42 fiieBen, und zwar in einer 
Weise, die effizient diircb den KontroUer 12 verwendet wer- 
den kann, um die Steuerung des gesamten Prozesses 19 zu 
bewirken. Um femer Informationen zu empfangen, die nicht 
synchron iiber den Bus 42 gesendet werden, muB der Kon- 
troUer 12 eine Anfrage nach dieser Information aussenden, 
die, wie oben erlautert wurde, asynchron iiber den Bus 42 
gesendet wird. Da es fur den KontroUer 12 keinen Weg gibt, 
zu bestimmen oder zu bevyirken, wann die asynchrone An- 
frage an die geeignete Vorrichtung ubergeben wird (da die 
Zeitsteuerung diese Anfrage direkt durch die anderen asyn- 
chronen Kommunikationen beeinfiuBt wird, die auf dem 
Bus 42 stattfinden), kann der KontroUer 12 Informationen 



empfangen, die nicht mehr aktueU sind, und zwar zu dem 
Zeitpunkt, wenn sie den KontroUer 12 erreichen. In ahnU- 
cher Weise hat der KontroUer 12 keine MogUchkeit zu be- 
stimmen, welche Daten es zu einem spezifischen Zeitpunkt 
5 sein soUen oder waren, was bei der Steuerung anderer Vor- 
richtungen innerhalb des Prozesses 19 wichtig sein kann, die 
nicht an den Bus 42 angeschlossen sind. Dariiber hinaus 
kann es schwierig oder unmoglich fur den KontroUer 12 
sein, wichtige Informationen zu empfangen, die den Status 

10 einer Vorrichtung ' oder eiries Funktionsblockes betreffen, 
und zwar innerhalb des Fieldbus-Abschnitts des Prozesses 
19, wie beispielsweise Alarme, die durch solche Funktions- 
blocke erzeugt werden. 

Um diese Probleme zu iiberwinden, kann der KontroUer 

15 12 so ausgelegt sein, uin die Schattenfunktionsblocke zu 
verwenden, um die Kommunikation mit den Vorrichtungen 
und den Funktionsblocken innerhalb des Fieldbus-Ab- 
schnitts des ProzeBregelnetzwerks 10 zu implementieren. 
SpezieUer gesagt, kann die Steuerroutine innerhalb des 

20 KontroUers 12 direkt mit einem Schattenfunktionsblock in- 
nerhalb des KontroUers 12 kommunizieren, der dann auto- 
matisch mit einem zugeordneten aktueUen extemen Funk- 
tionsblock mneriialb einer Bereichsvorrichtung kommuni- 

' ziert, die an den Bus 42 angeschlossen ist. Der Schatten- 

25 funktionsblock innerhalb des KontroUers 12 ist so konfigu- 
riert, um den Stand der und die Daten, die dem aktueUen ex- " 
temen Funktionsblock zugeordnet sind, innerhalb einer Vor- 
richtung nach unten izu spiegeln, die an den Bus 42 ange- 
schlossen ist, so daB es fiir die ProzeBsteuerroutinen inner- 

30 halb des KontroUers 12 so scheint, als ob der tatsachUche 
exteme Funktionsblock zugreifbar ist, ohne vermittels des 
Fieldbus-ProtokoUs iiber den Bus 42 kommunizieren zu 
miissen. Mit anderen Wortefi erscheint es fur die ProzeB- 
steuerroutine innerhalb des KontroUers 12 so, als ob der tat- 

35 sachUche Funktionsblock innerhalb des ProzeBkontrollers 
12 gelegen ware, anstatt unten innerhalb einer extemen Be- 
reichsvorrichtung, die an den Bus angeschlossen ist, und die 
ProzeBsteuerroutine verwendet den Schattenfunktionsblock 
so wie sie andere Funktionsblocke inrierhalb des KontroUers 

40 12 verwendet. 

Fig. 4 veranschauUcht eine graphische Einzelheit einer 
ProzeBregelschleife Oder eines Moduls 100, der der ProzeB- 
steuerroutine zugeordnet ist und durch diese implementiert 
ist, und zwar innerhalb des ProzeBkontrollers 12. Um die 

45 Steuerung des gesamten Prozesses 19 zu implementieren, 
kann die ProzeBsteuer- oder -regelroutine innerhalb des 
KontroUers 12 viele solcher Schleifen oder Module imple- 
mentieren, die in irgendeiner gewiinschten Weise miteinan- 
der verbunden sein konnen. Die herausgegriffene ProzeBre- 

50 gelschleife 100 enthalt eine Representation eines Aspektes 
(Russes) des Prozesses 101, der durch eine Anzahl von 
KontroUerblocken oder Einheiten gesteuert wird, spezieU 
durch einen PID-Block 102, der an einen AO-Block 104, ei- 
nen efsten AI-Block 106 und einen zweiten AI-Block 108 

55 gekoppelt ist. Jeder der Blocke 102, 104 und 106 ist eine 
graphische EinzeldarsteUung einer Regelsubroutine (oder 
eines Objektes innerhalb einer objektprientierten Program- 
nderuingeburig), die der ProzeBregelroutine zugeordnet ist, 
die in dem KontroUer 12 gespeichert ist, konfiguriert gemaB 

60 einem KontroUerprotokoU, welches dem KontroUer 12 zu- 
geordnet ist und dazu verwendet wird, um einen Abschnitt 
. ' einer Gesamtregelstrategie in bezug auf den ProzeB 101 zu - 
. implementieren. Jeder der Blocke der ProzeBregelroutine 
100 enthalt Eingange und Ausgange (durch Eingange auf 

65 der Unken und rechten S eite der Blocke jeweUs veranschau- ■ 
Ucht) und kann einen Steuer- oder Regelalgorithmus enthal- 
ten, der eine gewisse Steuer- oder Regelfunktion durchfuhrt. 
Verbindungen untereinander oder Verbindungen zwischen 
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den Funktionsblocken sind als Leitungen oder Linien darge- 
stellt, die von einem Ausgang von einem Block zu einem 
Eingang eines andefen Blocks verlaufen. Diese Verbindun- 
gen geben die Art wieder, in welcher die Konununikation 
zwisch'en den eirizelnen Blocken innerhalb der Steuerrou- 
tine Oder Modul implementiert wird, um eine ProzeBregel- 
schleife gemaB einem KontroUerprotokoll auszufuhren. So- 
mit veranschaulicht die Einzelheit von Fig, 4 nicht nur die 
Elemente der Regelschleife, die ausgefiihrt werden, sondem 
auch die Aft, in welcher die ProzeBregelroutine innerhalb 
des KontroUers 12 ausgelegt ist, um diese Schleife zu imple- 
mentieren. Die ProzeBregelroutine kann automatisch gean- 
dert Oder emeut konfiguriert werden, und zwar durch Bewe- 
gen der Verbindungen zwischen den Blocken, durch Addie- 



werden, urid zwar unter Verwendung eines Delta V-Steuer- 
sy stems (oder eines anderen zentralisierten Steuersy stems), 
bei dem der . Basissatz an Funktionsblocken, die in dem 
Steuersystem oder Regelsystem verwendet werden, ahnlich 

5 denjenigen ist, die durch das Fieldbus-ProtokoU definiert 
sind. Die extemen Fieldbus- oder herstellerspezifischen 
Funktionsblocke sind individueU zugeordnet, um in Verbin- 
dung mit dem Steuer- oder Regelsystem (oder einem TeiL 
des Steuer- oder Regelsystems) ein Programm auszufuhren 

10 und die Funktionsblocke der Fieldbus- Vorrichtungen sind in 
dem Steuer- oder Regelsystem als Schattenfunktionsblocke 
wiedergegeben oder reflektiert, welche interne und exteme 
Referenzen unterstutzen, so als ob die extemen Funktions- 



blocke in dem Steuer- oder Regelsystem vorhanden waren. 

ren oder Weglassen von Blocken davon us w. , wie dies durch 15 Das Steuer- oder Regelsystem emeuert automatisch die dy- 

den Delta V-ProzeBkontroUer ausgefiihrt wird. namischen und die statischeri Parameter des Schattenfunkti- 

^ Der PID-Funktionsblock 102, der in Fig* 4 veranschau- onsblocks und leitet Anderungsanfragen zu den geeigneten 

licht ist, enthalt einen Algorithmus (durch den Kontroller 12 extemen Funktionsblocken unter Verwendung der Schatten- 

implementiert), der beispielsweise eine Proportionai/Ente- funktionsblocke. Alamisignale, die in den extemen Vorrich- 

gral/Dififerential-Regelberechnung ausfuhrt, basierend auf 20 tungen (oder Funktionsblocken) detektiert werden, werden 



den EingangsgroBen, die er von den AI-B16cken 106 und 
108 und dem AO-Block 104 empfangt, und der ein Aus- 
gangssteuersignal fiir den AO-Block 104 erzeugt, welcher 
seinerseits eine Vorrichtung (28 beispielsweise ein Ventil) 
innerhalb des Prozesses 101 veranlaBt, eine Funktion durch- 
zufiihren, wie beispielsweise bewirken, daB ein Ventil be- 
wegt wird, um die Stromung eines Mediums zu erhohen. 
Der AO-Block 104 kann einem tatsachlichen Ventil zuge- 
ordnet sein und dieses steuem, z. B. das Ventil 28 von Fig, 1, 
und zwar uber die lO- Vorrichtung 20 und die 4-20-mA- 
Konmiunikationsieitung 38. Der AO-Block 104 empfangt 
eine Messung der tatsachlichen Position des Ventils uiid lie- 
fert diese Messung als eine RiickkopplungsgroBe zu dem 
PID-Funktionsblock 102 uber die Verbindung 110. Daruber 



in den Schattenfunktionsblocken reflektiert und werden in 
der Alarmverarbeitung des Steuer- oder Regelsystems inte- 
griert. Naturlich kommuniziert der Schattenfunktionsblock 
mit den extemen Funktionsblocken unter Verwendung des 
25 KontrollerprotokoUs, welches den externen Funktionsblok- 
ken zugeordnet ist, welches verschiedeii von dem Kontrol- 
lerkonfigurationsprotokoll sein kann und typischerweise 
verschieden ist, welches von dem KontroUer verwendet 
wird, um die Konununikationen zwischen den Funktions- 
30 blocken intern zu dem Kontroller zu implementieren. Auch 
konnen Verbindungen zwischen intemen und extemen 
Funktionsblocken durch deh Anwender in einer Weise be- 
stimmt werden, die davon abhangt, wo der Funktionsblock 



vorhanden ist. Als ein Ergebnis erscheinen wahrend der 
hinaus empfangt der PID-Funktionsblock 102 Eingangsgro- 35 Steuerdefinition und der Online-Diagnose die Funktions- 
Ben von dem AI-Block 106, der beispielsweise einem Sen- blocke als die gleichen, ob sie nun interne (in dem Steuer- 
sor, wie einem Temperatursensor, zugeordnet ist, der inner- oder Regelsystem vorhanden) oder exteme (in einer Field- 
halb des Prozesses 19 gelegen ist Dieser Sensor kann bei- bus- Vorrichtung vorhanden) sind oder nicht. 
spielsweise der Sensor 34 von Fig. 1 sein, in welchem FaU Somit ist gemaB der vorUegenden Erfindung der AI- 

der AI-Block 106 die SensormeBgroBen uber die I/O-Vor- 40 Block 108, der in Fig. 4 so dargesteUt ist, daB er ahnlich dem 
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richtung 22 empfangt, und zwar unter Verwendung von 
Standardnachrichteniibertragungen. Solch eine Verbindung 
ist in Fig. 4 durch die Verbindung zwischen dem Ausgang, 
der mit "RuB" in dem ProzeB 101 bezeichnet ist, und dem 
Eingang des AI-Blocks 106, der mit "simulate_in" bezeich- 
net ist, verarischaulicht. Die Verarbeitung und die Steuemng 
der Information, die dem PID-Funktionsblock 102, dem 
AO-Block 104 und dem.Al-Block 106 zugeordnet ist, wird 
innerhalb des KontroUers 12 durchgefuhrt. 

AUgemein gesagt, ist innerhalb des Delta V-Steuersy- 
stems, das heiBt Verwendung des Delta V-KontroUerkonfi- 
gurationsprotokolls jeder der. Blocke 102, 104 und 106 spe- 
zifisch konfiguriert, um all die Informationen und Daten zu 
unterstutzen, die den ahnlichen Funktionsblocken in dem 
Fieldbus-ProtokoU zugeordnet sind und somit fur aUe Ab- 
sichten und Zwecke, und ist sehr ahnUch einem Funktions- 
block innerhalb des Fieldbus-ProtokoUs mit der Ausnahme, 
daB die Steuerfimktionen oder Regelfunktionen durch den 
zentralen Prozessor 12 durchgefuhrt werden und daB die Ih- 
. formationen von spezieUen Bereichsvorrichtungen iiber 
Standardkomimunikationsleitungen von dem ProzeBkontrol- 
ler 12 empfangen und iibeigeben werden. Somit sind die 
Abschnitte der Steuer- oder Regelroutine, die in Fig, 4 her- 
ausgegriffen ist, welche die Blocke 102, 104 und 106 ent- 
halt, momeritan in der Delta V-Umgebung vprgesehen und 65 
sind bekannt. 

Um die Fieldbus-Integration innerhalb des KontroUers 12 
zu unterstutzen, kann die folgende Annaherung versucht 



AI-Block 106 ist, tatsachlich ein Schattenfunktionsblock, 
der so konfiguriert ist, daB er mit einem extemen Funktions- 
block 112 kommuniziert, der beispielsweise innerhalb des 
Sensors 48 gelegen ist, der an den Fieldbus 42 von Fig. 1 an- 
geschlossen ist, Der Schattenfunktionsblock 108 liefert ge- 
messene oder andere Signale, die dem extemen Funktions-. 
block 112 zugeordnet sind, an den PID-Block 102 iiber die 
Verbindungen, die dazwischen ersteUt wurden. Um anzuzei- 
gen, daB der Block 108 ein Schattenfunktionsblock ist, der 
50 einem extemen Funktionsblock ll2 zugeordnet ist und mit 
diesem kotnmuniziert,' unter Verwendung des,Kommunika- 
tionsprotokoUs des extemen Funktionsblockes 112, ist der 
Block 108 so dargesteUt, daB er eine' strichUerte Linie be- 
sitzt, die an den AI-Funktionsblock 112 innerhalb der Field- 
55 bus- Vorrichtung 48 angehangt ist. Jedoch kann der Schat- 
tenfunktionsblock 108 so dargesteUt sein, daB er eine Vor- 
richtungsetikette (device tag) und/oder einen Blocknamen 
am Boden desselben besitzt, oder kann in irgendeiner ande- 
ren gewiinschten Weise dargesteUt sein, wobei darauf hinge- 
wiesen sei, daB die Art, in welcher der Schattenfunktions- 
block fiir einen Anwender als Einzelheit dargesteUt ist, nicht 
kritisch ist, und zwar in Verbindung mit dem Betrieb des 
Schattenfunktionsblocks. Femer werden die Eingangsgro- 
Ben und AusgangsgroBen, die dem AI-Funktionsblock 112 
zugeordnet sind, innerhalb des Fieldbus-Netzwerks gemaB 
dem Weg iibergeben, in welchem das Netzwerk konfiguriert 
worden ist 

Wahrend der Schattenfunktionsblock l08 auf aUe oder 
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die meisten der Informationen zugreift oder spiegelt, die 
dem tatsachlichen Funktionsblock 112 zugeordnet sind und/ 
Oder durch diesen erzeugt warden, erfolgt irgendeine Verar- 
beitung, die in bezug auf die AI-Funktionsblock 112 stattfin- 
det (oder in bezug auf irgendeinen anderen Funktionsblock, 
fur den ein Schattenfunktionsblock existiert) in dieser Weise 
unten in der extemen Vorrichtung, nicht in dem Schatten- 
funktionsblock 108 Oder selbst in dem Kontroller 12. Als ein 
Ergebnis kann der Schattenfunktionsblock 108 so betrachtet 
werden, als ob er eine Rohre von Informationen zwischen 
dem PID-Block 102 (odeir irgendeinem anderen Block in- 
nerhalb des zentralisiert^n KontroUers 12) urid dem tatsach- 
liehen Funktionsblock 112 bilden wiirde. Der Schattenfunk- 
tionsblock 108 ist nicht ein Funktionsblock, der vollstandig 
durch den Kontroller 12 betreibbar ist, in dem Sinn, da6 der 
AI-Block 106 und der PID-Block 102 durch den Kontroller 
12 betreibbar sind, da der Schattenfunktionsblock 108 ledig- 
lich die Informationen innerhalb des tatsachlichen extemen 
Funktionsblocks. 112 spiegelt oder ansonisten eine Nachrich- 
teniibertragung zwischen dem Kontroller 12 und dem tat-^ 
sachlichen extemen Funktionsblock 112 vorsieht. Nichtsde- 
stbweniger kann durch eine geeignete Operation des Schat- 
tenfunktionsblockes der Kontroller 12 den tatsachlichen 
Funktionsblock 112 steuem und mit diesem konununizie- 
ren, so als ob dieser vollstandig in dem KontroUer 12 imple- 
mentiert ware, Indem beispielsweise eine Kommiinikation 
mit dem Schattenfunktionsblock 108 durchgefiihrt wird, un- 
ter Verwendung des Kontrollerkonfigurationsprotokolls, 
kann die ProzeBsteuer- oder -regelroutine innerhalb des . 
KontroUers 12 auf den neuesten Stand gebrachte Informa- 
tionen von dem Funktionsblock 112 empfangen und kann 
Befehle zu dem Funktionsblock 112 so schneU wie moglich 
senden, ohne sich damm kiimmem zu miissen, wo der tat- 
sachliche Funktionsblock 112 gelegen ist oder auf welche 
Weise Kommunikationen mit dem tatsachlichen Funktions- 
) block 112 bewirkt werden. Statt dessen erfolgen die Kom- 
munikationen zwischen dem tatsachlichen Funktionsblock 
112 und dem Schattenfunktionsblock 108 automatisch ohne 
Eihgreifen durch die ProzeBsteuerroutine, die lediglich die 
Schritte ausfiihlren muB, die sie in typischer Weise ausfiihrt, 
um die Kommunikationen zwischen den Steuer- oder Funk- " 
tionsblocken zu implementieren, die innerhalb des Kontrol- 
lers 12 gelegen sind. In dieser . Weise ermoglicht es der 
Schattenfunktionsblock einem KontroUer, der Funktions- 
blocke innerhalb des KontroUers implemehtiert, Funktions- 
blocke zu verwenden und nut zu ihtegrieren, die unter- 
schiedliche Kommunikations- oder Konfigurationsproto- 
koUe verwenden und die nicht innerhalb des KontroUers ge- 
legen sind, sondem die statt dessen in einer externen Vor- 
richtung gelegen und in diese implementiert sind, wie bei- 
spielsweise einer mikroprozessor-unterstiitzten Bereichs- 
vorrichtung, die in einer ProzeBumgebung angeordnet ist. 
Diese hinzugefugte Fahigkeit wird von dem KontroUer 12 in 
transparenter Weise erreicht, so daB dann, sobald der Schat- 
tenfunktionsblock in dem KontroUer 12 aufgebaut ist, die 
Steuer- oder Regekoutine nicht nachzusuchen braucht, wq 
der tatsachUche Funktionsblock gelegen ist, um komplexe 
Kommunikationen oder Datenbasismanipulationen durch- 
zufiihren, um den extemen Funktionsblock 112 zu verwen- 
den. 

Wie hervorgeht, speichert der. Schattenfunktionsblock 
108 die EingangsgroBen und AusgangsgroBen der parame- 
trischen Updates, die dem AI-Funktionsblock 112 in einer 
Datenbasis in dem KontroUer 12 zugeordnet sind, und zwar 
in irgendeinem gewiinschten Format, speichert jedpch in be- 
yorzugter Weise diese in dem gleichen oder einem ahnUchen 
Format wie die Informationen, die den Steuerblocken zuge^ 
ordnet sind, die durch den KontroUer implementiert sind, 



das heiBt unter Verwendung des KontrbUerkonfigurations- 
protokoUs. Dies macht die Kommunikation nut dem Schat- 
tenfunktionsblock 108 fiir den KontroUer 12 transparent, 
das heiBt die ProzeBsteuer- oder -regekoutine 100 schafft 

5 eine Kommunikation in bezug auf den Schattenfunktions- 
block 108 (und somit mit dem tatsachUchen Funktionsblock 
. 112) iiber die Verbindung in der gleichen Weise wie sie eine 
Kommunikation in bezug auf die anderen Funktionsblocke 
104 und 106 erzeugt. Wahrend es wiinschenswert ist, daB 

10 die Funktionsblocke\innerhalb des KontroUers 12 logisch 
konfigiiriert sind, um aU die Informationen (oder die mei- 
sten) zu unterstiitzen, die durch das dezentraUsierte oder ex- 
terae ProzeBregelnetzweik uriterstiitzt werden (wie dies bei 
dem Delta V-KontroUer und dem Fieldbus-Kommunikati- 

15 onsprotokoU der FaU ist), so ist diese Konfiguration nicht er- 
forderUch. TatsachUch kann irgendein KontroUeraufbaii un- 
ter Verwendung des Schattenfunktionsblockes unterstiitzt 
werden, der hier offenbart ist, indem die Daten, die in dem 
externen Funktionsblock unterstiitzt werden und in diesem 

20 verfiigbar sind, in den Daten abgebUdet werden,. die in der 
KontroUerroutine verwendet und verfiigbar sind. 

Allgeinein gesagt, um den Betrieb dels Schattenfunktions- 
blockes 108 in dem Fieldbus-Netzwerk zu bewirken, wird 
der tatsachliche Funktionsblock 112 so konfiguriert, um die 

25 verketteten Daten zu veroffentHchen und an den ProzeBkon- 
trbUer 12 (das heiBt die Daten, die mit einem anderen Block 
innerhalb des KontroUers 12 iiber eines der Verbindungs- 
gUeder, die ift Fig. 4 veranschauHcht sind, verbunden sind) 
oder zu veroffentlichen, und zwar iiber die Schnittstellen- 

30 karte 40, unt^ Verwendung des Verof fentlicher^eihiehmer- 
VCR's (das heiBt synchronen Kommunikationen) in dem 
Fieldbus-Kommunikationsprotokoll. Andere nicht vprket- 
tete Daten, die dem tatsachUchen Funktionsblock 112 zuge- 
ordnet sind, werden an die SchnittsteUenkarte 40 unter Ver- 

.35 wendung von asynchronen Kommunikationen bzw. Nach- 
richteniibertragungen iibergeben, unter Verwendung von 
beispielsweise den Betrachtungsobjekt- oder Wamobjekt- 
fiinktionen innerhalb des Fieldbus-ProtokoUs, was in der 
Modulabtastrate des Steuermoduls innerhalb des Kontrol- 

40 lers 12 stattfindet. Es werden daher in typischer Weise ver- 
kettete Daten zu dem KontroUer 12 von dem Funktions- 
block 112 in einer sehr viel schneUeren Rate gesendet als an- 
dere Daten (weniger zeitsensitive Daten). Umgekehrt wer- 
den verkettete Daten, die durch einen Block innerhalb des 

45 KontroUers 12 zu dem Schattenfunktionsblock 108 gesendet , 
werden, unmittelbar an die SchnittsteUen vorrichtung 40 
weitergeleitet, wo sie auf dem Fieldbus-Bus. 42 unter Ver- 
wendung von synchronen Standardnachrichteniibertragun- 
gen veroffentlicht werden. 

50 Die Informationen, die von dem tatsachUchen Funktions- 
block 112 gesendet werden, werden automatisch in den 
Schattenfunktionsblock 108 gesetzt und stehen somit fiir die 
Steuer- oder Regelroutine in dem KontroUer 12 zu jeder Zeit 
zur Verfiigung. Um diese Operation zu bewirken, nimmt die 

55 SchnittsteUenkarte 40 (die Teil eines Konomunikationsports 
des Schattenfunktionsblockes sein kann) teil an den verbf- 
fentUchten Verbindungsparameterdaten, die durch den 
Funktionsblock 112 erzeugt wurden, und Uefert diese Infor- 
mationen zu dem ProzeBkontroUer 12 in der Rate, die durch 

60 die Ausfiihrungsrate des Funktionsblockes innerhalb des 
Makrozyklusses des Fieldbus^Segments festgelegt ist, an 
welches der exteme Funktionsblock 112 angeschlossen ist. 
In ahnUcher Weise erhalt die SchnittsteUenkarte 40 (die ty- 
pischerweise das LAS des Fieldbus-Segments ist) die Be- 

65 'trachtungsobjekte und/oder Wamobjekte des tatsachUchen 
• Funktionsblocks in einer Rate, die durch die Abtastrate des 
KontroUermoduls festgelegt ist, in welchem der Schatten- 
funktionsblock 108 vorhanden ist, das heiBt in der Rate, in 
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welcher die Steuer- oder Regelroutine 100 in dem Kontrol- 
ler 12 die Blocke implementiert, die dieser zugeordnet sind. 
Wie dies bekannt ist, enthalt das Fieldbus-Protokoll vier Ty- 
pen von Betrachtungsobjekten, die die normalerweise dyna- 
mischen (Betrachtungsobjekt 1), normalerweise statischen 
(Betrachtungsobjekt 2), alle dynamischen (Betrachtungsob- 
jekt 3) und alle statischen (Betrachtungsobjekt 4) Variablen 
speichern. Die Schnittstellenkarte 40 ist so konfiguriert, um 
automatisch auf einer periodischen Grundlage oder durch 
Aussenden einer Anfrage nach solchen Infonnationen das 
dynamische Betrachtungsobjekt 3 zii empfangen, welches 
die Werte fur aUe die dynamischen Variablen enthalt, die 
dem tatsachHchen Funktionsblock 112 zugeordnet sind. 
Nach Empfangen dieser Betrachtungsobjektinformationen 
speichert die Schnittstellenkarte 40 die Informationen in ei- 
ner Datenbasis oder Datenbank, die durch den Schatten- 
funktionsblock zugreifbar ist, und der .Schattenfunktions- 
block 108 emeuert die- Variablen, die sich dadurch geandert 
haben, wodurch diese variablen Werte fur die ProzeBsteuer- 
oder -regelroutine innerhalb des KontroUers 12 verfiigbar 
werden. Wenn eine der dynamischen Variablen (die stad- 
sche.Revisionsvariable) eine Anderung an einer statischen 
Variablen anzeigt, kann der Schattenfunktionsblock oder die 
Software innerhalb der Schnittstellenkarte 40 anfragen, daB 
das Betrachtungsobjekt 4 (alle statischen Variablen) zu dem 
Schattenfunktionsblock 108 gesendet werden, um die stati- 
schen Variablen auf den neuesten Stand zu bringen. Bei der 
bevorzugten Ausfuhrungsform empfangt die Hl-Schnitt- 
stellenkarte 40 fortlaufend das Betrachtungsobjekt 3 in der 
Modulabtastrate des Steuermoduls 100 innerhalb des Kon- 
■ troUersl2. . 

Wie oben dargelegt ist, kann der Kontroller 12 (oder ir- 
gendein Funktionsblock desselben) Befehle zu dem aktuel- 
len Funktionsblock 112 innerhalb des Fieldbus-Netzwerks 
iiber den Schattenfunktionsblock 108 einfach dadurch sen- 
den, indem ein Parameter innerhalb des Schattenfunktions- 
blockes 108 geandert wird. Diese Parameteranderung wird 
automatisch nach unten zu dem AI-Funktionsblock 112 tiber 
einen Ausgang des Schattenfunktionsblockes 108 gesendet, 
wo er dazu verwendet wird, um die Konfiguration des AI- 
Funktionsblockes 112 zu andern. Wahrend die Datenande- 
rung 'oder der Einschreibbefehl in dem tatsachlichen Funk- 
tionsblock 112 nicht zu exakt der gleichen Zeit durchgefiihrt 
wird, zu der dieser durch den Schattenfunktionsblock 108 
.empfangen wird, und zwar vom Standpunkt des KontroUers 
12 aus, erfolgt diese Anderung sehr schnell und wird in den 
Schattenfunktionsblock 108 zuriick reflektiert, wenn die 
Anderung tatsachlich vorgenommen wurde. Diese Betriebs- 
weise ^rmoglicht es dem Kontroller 12. und speziell dem 
PID-Funktiorisblock 102, innerhalb des KontroUers 12 eine 
Anderung zu bewirken, indem lediglich diese Anderung in 
eine SpeichersteUe eingeschrieben wird, die dem Schatten- 
funktionsblock 108 zugeordnet ist und indem danach die 
Kommunikation automatisch vorgenommen wird, ohne daB 
dabei irgendwelche speziellen Kommunikationsaktivitaten 
ausgefiihrt werden miissen, die erforderUch sind, um Daten 
in das Fieldbus-Netzwerk hinein zu bekommen und heraus 
zu bekommen. 

Neben den Eingangs- und Ausgangsparameterdaten kon- 
nen andere TVP^^^ voti Daten, wie beispielsweise Modus- 
und Statiisdaten, zwischen einem KontroUerfunktionsblock 
(das heiBt einem intemen Funktionsblock) und dem Schat- 
tenfunktionsblock 108 iibertragen werden als auch zwischen 
dem Schattenfunktionsblock 108 und dem tatsachHchen ex- 
temen Funktionsblock 112. Natiirlich wird diese Informa- 
tion mit den Betrachtungsobjekt- oder Wamobjektinforma- 
tionen von dem extemen Funktionsblock 112 zu dem'*Schat- 
tenfunktionsblock 108 gesendet. In ahnMcher Weise konnen 



solche Modus- und Statusdaten an den Schattenfunktions- 
block 108 von einem intemen Funktionsblock innerhalb des 
KontroUers 12 iibermittelt werden und es konnen diese Da- 
ten dann an den extemen Funktionsblock 112 fiir die Ver- 
5 wendung geliefert werden. Der Statusparameter eines Funk- 
tionsblockes zeigt in typischer Weise die Qualitat der Mes- 
sung Oder der Daten an, die durch den Funktionsblock gelie- 
fert werden, und kann Griinde Hefem, warum eine schlechte 
(Jualitat existiert. Er kann auch eine Grenze anzeigen, wie 
10 beispielsweise eine hohe oder niedrige Grenze, welche die 
Daten erreichen konnen, Der Modusparameter zeigt in typi- 
scher Weise an, welcher Modus des Funktionsblocks einge- 
schaltet ist, welcher beispielsweise ein Handmodus, ein Au- 
tomatikmodus oder ein Kaskadenmodus sein kann, wie dies 
15 durch das Fieldbus-ProtokoU festgelegt ist. 

Daruber hinaus wird eine Alarmdetektion basierend auf 
Alarmsignalen, die in dem tatsachUchen externen Funk- 
tionsblock erzeugt werden, vorgesehen, da Ereignisse und 
Berichte durch den extemen Funktionsblock automatisch als 

20 dynamische Parameter erzeugt werden, die dann durch die 
Betrachtungs- oder Wamobjekte dem Schattenfunktions- . 
block 108 angeboten werden. Als. ein Ergebnis kann eine- 
Alanninf ormation , die den extemen Funktionsblock betrifft, 
von dem KontroUer 12 betrachtet und verwendet werden. 

25 ObwoW natiirlich der Block 108 hier als Schattenfunkti- 
onsblock beschrieben wurde, konnen irgendwelche Blocke 
innerhalb der Fig, 4 ebenfaUs oder altemativ Schattenfunk- 
tionsblocke sein. 

Die Vorteile, die mit der Verwendung eines Schattenfunk- 

30 tionsblockes verbunden sind, wie beispielsweise dem Schat- 
tenfunktionsblock 108, der in Fig. 4 veranschaulicht ist, be- 
stehen darin, daB dieser es dem ProzeBregeldesigner ermog- 
licht, die Steuerung oder Regelung innerhalb eines zentraU- 
sierten ProzeBkontroUers 12 zu implementieren unter Ver- 

35 wendung von extemen Funktionsblocken, das heiBt Funk- 
tionsblocken, die tatsachlich innerhalb einer verschiedenen 
Vorrichtung implementiert sind und die unterschiedlichen 
KommunikationsprotokoUen unterworfen sind. In Verbin- 
dung mit dem Schattenfunktionsblock braucht ein Designer 

40 Oder Konstrukteur sich nicht darum zu kummem, daB der 
exteme Funktionsblock einem unterschiedlichen Kommuni- 
kations- oder Steuer- oder RegelprotokoU zugeordnet ist 
Oder in einer unterschiedlichen Vorrichtung gelegen ist, da 
die Nachrichteniibermittiung zwischen dem Schattenfunkti- 

45 onsblock und dem extemen Funktionsblock automatisch er- 
folgt und auch transparent fiir die Steuer- oder Regelroutine. 
Wenn femer einmal ein Schattenfunktionsblock implemen- 
tiert ist und lauft, ist es einfach ein ModeU daruber zu erstel- 
len, was sich innerhalb des gesamten ProzeBregeisy stems 

50 ereignet, und zwar ohne sich darum zu kummern, ob Aktio- 
. rien innerhalb einer Fieldbus- oder anderen extemen Vor- 
richtung auftreten oder innerhalb des KontroUers auftreten, 
da der Schattenfunktionsblock fur den KontroUer und den 
Anwender bewirkt, daB es so scheint, daB der tatsachUche 

55 Funktionsblock in dem KontroUer implenientiert ist, ob wohl 
dies real nicht der FaU ist. 

Wenn ein gemeinsamer Funktionsblocksatz und Schatten- 
fiihktionsblocke in dem Steuer- .oder Regelsystem verwen- 
det werden, um Funktionsblocke wiederzugeben, die exter- 

60 nen Vorrichtungen zugeordnet sind, kann die Steuer- oder 
Regelstrategie zu Beginn ohne das Wisseri ausgelegt wer- 
den, ob ein bestimmter Funktionsblock dieser Strategic in 
dem Steuer- oder Regelsystem vorhanden sein wird oder in 
einer extemen Vorrichtung vorhanden sein wird, und es kon- 

65 nen Anwenderanwendungen auf die Schattenfunktions- 
blocke zugreifen (welche die extemen Funktionsblocke wie- 
deirgeben oder als ModeU darsteUen), und zwar in exakt der 
gleichen Weise wie sie auf die Steuer^ oder Regelsystem- 
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funktionsblScke zugreifen. Auch werden Alarme, die durch 
die exteme Vorrichtung detektiert werden, voll in die Steu- 
ersystemalarmverarbeitung durch den Schattenblock inte- 
griert, mit der Moglichkeit, daB diese Alarme in exakt der 
gleichen Weise fur die extemen Funktionsblocke erscheinen 5 
wie fiir Funktionsblocke, die innerhalb des Steuer- oderRe- 
gelsystems vorhanden sind. 

Die Konfigiaration, Implementierung und Verwendiing ei- 
nes Schattenftinktionsblockes wird nunmehr in Einzelheiten 
unter Hinweis auf die Fig, 5-13 beschrieben. Fig, 5 veran- 10 
schauUcht den physikalischen Aufbau eines Abschnitts des 
ProzeBregelnetzwerks von Fig. 1 mehr in Einzelheiten. Die 
Anwenderworkstation 150, die aus irgendeinem der PCs 14 
von Fig. 1 bestehen kanh, ist kommunikativ mil dem Kon- 
troller 12 verbunden, der seinerseits iiber die SchnittsteUen- 15 
karte 40 mit der Bereichsvorrichtung 48 verbunden ist, wel- 
che den Funktionsblock 112 darin enthalt. Wie in Fig. 5 ver- 
anschaulicht ist, besitzt der Kontroller 12 einen oberen Ab- 
schnitt 152, in welchem die Steuerroutine 100 (enthaltend 
den.Schattenfunktionsblock 108) implementiert ist, und ei- 20 
nen .unteren Abschnitt, der eine Datenbasis oder Datenbank 
156 enthalt, um Eingangs- und Ausgangsinformationen zu 
speichem, die von der Schnittstellenkarte 40 als auch von 
anderen I/O-Karteri empfangen werden. Allgemein gesagt, 
ist die Schnittstellenkarte 40 so konfiguriert, um automa- 25 
tisch verkettete Daten zu empfangen, die durch den Funk- 
tionsblock 112 veroffentlicht werden, und zwar uber den 
Veroffentlicher/Teihiehmer-VCR (in der Veroffentlichungs- 
rate, die durch den Makrozyklus des Fieldbus-Busses 42 
festgelegt ist), und um diese Daten in der unteren Datenbank 30 
156 zu speichern, wo sie dem Schattenfunktionsblock 108 in 
' der Abtastrate des Steuermodus 100 innerhalb des Kontrol- 
lers l2 angeboten werden. In ahnlicher Weise ist die Schnitt- 
stellenkarte 40 so konfiguriert, um die verketteten Daten, die 
durch einen Funktionsblock innerhalb des KontroUers 12 er- 35 
zeugt werden, auf dem Fieldbus-Bus 40 zu veroffentlichen, 
unter Verwendung synchroner Nachrichtenubermitdiingen 
innerhalb des Fieldbus-Netzwerks. Auch ist die Schnittstel- 
lenkarte 40 so konfiguriert, um periodisch anzufragen nach 
(unter Verwendung asynchroner Nachrichtenubertragun- 40 
gen) Betrachtungs- und/oder Alarmdaten von dem Funk- 
donsblock 112 und um diese Informationen in der unteren 
Datenbank 156 zu speichem, um sie an den Schattenfunkti- 
onsblock 108 in der Abtastrate des.Konnrollermoduls 100 zu 
liefern. . 45 

Die Schnittstellenkarte 40 und/oder die Datenbasis 156 
kann einen Kommunikationsport des Schattenfunktions- 
blockes 108 umfassen, kann Teil von diesem sein oder kann 
durch diesen gesteuert sein, der Kommunikationen zwi- 
schen dem Schattenfunktionsblock 108 und dem extemen 50 
Funktionsblock 112 implementiert Der Komimunikations- 
port enthalt einen Eingang, der von dem extemen Funk- 
tionsblock 112 Daten empfangt, und zwar unter Verwen- 
dung des Kommunikationsprotokolls des extemen Funk- 
tionsblocks 112, und enthalt einen Ausgang, der mit dem ex- 55 
■ temen Funktionsblock 112 in Verbindung steht, um Daten ; 
(inklusive Schreibbefehlen) an den extemen Funktionsblock 
112 unter Verwendung des Kommunikationsprotokolls des 
extemen Funktionsblocks 112 zu senden. Natiirlich kann der 
Kommunikationsport des Schattenfunktionsblocks 108 in 60 
• der Software und/oder einer anderen Hardware in dem Kon- 
troUer zusatzlich oder in Verbindung mit der Schnittstellen- 
karte 40 und der Datenbank 156 implementiert sein. 

Urn eine Steuer- oder Regekoutine unter Verwendung ei- 
nes Schattenfunktionsblocks zu konfigurieren, kann ein An- 65 
wender bei der Workstation 150 irgendwelche Standard- 
werkzeuge verwenden, wie beispielsweise solche, die durch . 
das Delta V- Steuer- oder -Regelsystem geschaffen werden. 



um zu Beginn das ProzeBregelsystem zu konfigurieren. Im 
aUgemeinen ennoglichen es die Delta V-Konfigurations- 
werkzeuge einem Anwender, Blocke darzustellen, zu konfi- 
gurieren und miteinander zu verbindein, wie beispielsweise 
diejenigen, die in Fig, 4 veranschaulicht sind, um eine oder 
mehrere Regelschleifen zu implementieren odei* zu konstru- 
ieren Oder Module, die der Steuer- oder Regelroutine zuge- 
ordnet sind. Zum Zwecke der Erlauterung kann die Steuer- 
routine zum Steuera eines Prozesses irgendeine Anzahl von 
Modulen enthalten, von denen jeder irgendeine Anzahl von 
gewunschten Blocken enthalten kann, die eine Anzahl von 
Regelschleifen implementieren. Wahrend der Konfiguration 
oder der Konstmktion eines ProzeBregelmoduls kann ein 
Anwender die Verwendung eines Funktionsblocks auswah- 
len, der innerhalb einer Vorrichtung extern zum Kontroller 
12 gelegen ist (wie beispielsweise einen Funktionsblock in- 
nerhalb einer der Fieldbus-Vorrichtungen des ProzeBregel- 
systems). In diesem Fall kann das Konfigurationswerkzeug, 
welches dem Kontroller 12 zugeordnet ist, so konstruiert 
sein, um den Anwender zu fragen, die physikalischen der 
Verbindungen der Vorrichtung zu dem Kontroller 12 zu spe- 
zifizieren und andere Vorrichtungs- und Funktionsblock- 
konfigurationsinformationen zu spezifizieren, die fur die an-, 
fangliche Konfiguration der Vorrichtung und/oder des Funk- 
tionsblockes innerhalb der Vorrichtung gemaB dem Kom- 
munikationsprotokoll dieser Vorrichtung erforderlich sind 
(z. B. das Fieldbus-KommuiukationsprotokoU). Der An- 
wender kann dann aufgefordert werden, diese Informatio- 
nen in irgendeiner gewunschten Weise.zu liefem, wie bei- 
spielsweise iiber die Verwendung von Dialogkastchen. Na- 
tiirlich hangt die exakte Information, die benotigt wird, von 
dein Typ der Vorrichtung und des Funktionsblockes ab, der 
spezifiziert wird, \yie dies von einem Fachmann in Verbin-' 
dung mit dem VorrichtungsprotokoU, welches verwendet 
wird, wie beispielsweise dem Fieldbus-Protokoll, zu erken- 
nen ist. . 

Ein Weg, um zu spezifizieren, daB. ein Funktionsblock 
durch eine bestimmte exteme Vorrichtung (wie beispiels- 
weise eine Fieldbus- Vorrichtung) zu implementieren ist, be- 
steht darin, den Anwender dazu zu bringen, den Funktions- 
block, der innerhalb einer extemen Vorrichtung gelegen ist, 
zu spezifizieren, unter Verwendung eines Browsers (oder ei- 
ner anderen Software) oder einer Liste oder durch Heraus- 
greifen der extemen Vorrichtungen, die an den KpntroUer 
angeschlossen sind, und dann Auswahlen von einer der auf- . 
gelisteten extemen Vorrichtungen als die Vomchtung, in 
welcher der Funktionsblock zu implementieren ist. Ein an- 
derer Weg besteht darin, den Funktionsblock auf dem Bild- 
schirm auszuwahlen und dann diesen Funktionsblock auf 
eine Einzelheit eines Blocks in einer extemen Vorrichtung 
durch Drag and Drop zu bewegen. Irgendeine dieser oder ir- 
gendeine andere gewiinschte Aktiori kann dem Konfigurati- 
.onswerkzeug mitteilen, daB der Funktionsblock, der imple- 
mentiert werden soli, innerhalb der extemen Vorrichtung 
liegt, und kann das Konfigurationswerkzeug veranlassen, 
den Anwender nach der spezifischen Vorrichtung und deii 
Funktionsblockkonfigurationsinformationen zu fragen, die 
erforderlich sind, um den speziellen extemen Funktions- 
block zu konfigurieren und auf diesen zuzugreifen. Beide 
diese Verfahren ermoglichen es einem Anwender, einen 
Funktionsblock in einer extemen Vorrichtung aus einer Li- 
ste von extemen Vorrichtungen fiir die AusfUhmng eines 
Programms auszuwahlen.- 

Wenn der Anwender spezifiziert, daB ein extemer Funk- 
tionsblock zu verwenden ist (das heiBt extern vom Kontrol- 
ler 12),. so erstellt die Konfigurationsroutine dann einen 
Schattenfunktionsblock in dem KontroUer und untemimmt 
Schritte, um die Fieldbus- Vorrichtung und den Funktions- 
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block innerhalb der- Voirichtung zu konfigurieren, wie dies 
im folgenden beschrieben wird. NatiirKch erlaubt es das 
Konfiguratioriswerkzeug in bevorzugter Weise dem Anwen- 
, der, alle die Blocke, die zu verwenden sind, zu spezifizieren, 
ebenso die Ortlichkeiten oder Lagen solcher Blocke (das 
heiBt, ob irgendein Block in extemen Vomchtungen gelegen 
ist) und auch die Verbindungen zwischen den Blocken, be- 
vor die Schattenblocke implementiert werden uhd die exter- 
nen (z. B. Fieldbus-)Vorrichtungen initialisiert werden. Dies 
ermoglicht es, die Konfiguration des extemen Netzwerks 
einnaal auszuf iihren, nach dem die Ortlichkeit oder Lage von 
alien den Blocken und auch die Natur von alien Verbindun- 
gen zwischen den Funktionsblocken spezifiziert worden ist. 

In Verbindung mit der Befahigung des KontroUers, die 
Parameterdaten fur die Funktionsblocke innerhalb der exter- 
nen Vorrichtungen einzusehen oder Zugriff auf diese zu ha- 
ben (uber den Schattenfiinktiorisblock), kann die Schnitt- 
stellenkarte 40 auch Vorrichtungs- und Segmentstatusinfor- 
mationen an den Kontroller fur Diagnosezwecke liefem. Die 
Schnittstellenkarte 40 kann beispielsweise eine Liste emp- 
fangen, die eine Identifikation der Vorrichtungen enthalt, die 
angenommenermaBen an einem bestimmten Abschnitt oder 
, Segment des Fieldbus-Netzwerks angehangt oder ange- 
schlossen sind, und sachdienliche Informationeri uber jede 
der identifizierten Vorrichtungen enthalten. Die Schnittstel- 
lenkarte 40 kann dann periodisch Informationen (uber syn- 
chrone oder asynchrone Nachrichtenverbindungen) erhal- 
ten, welche die Vorrichtungen betreffen, die tatsachlich an 
das Fieldbus-Segment angeschlossen sind oder die das Seg- 
ment selbst betreffen, und kann diese Informationen mit den 
Informationen innerhalb der empfangenen Liste verglei- 
chen. Auf dieise Weise kann die Schnittstellenkarte 40 be- 
stimmen, ob die Biereichsvorrichtungen fehlen oder nicht an 
das Fieldbus-Netzwerk angeschlossen sind, ob falsche Be- 
reichsvorrichtungen an das Fieldbus-Netzwerk angeschlos- 
sen sind, ob eine Bereichsvorrichtung sich dem Service ent- 
zieht, usw. In ahnlicher Weise kann die Schnittstellenkarte 
40 bestimmen, ob Segmentwertprobleme auftreten, so als 6b 
keine Nachrichtenverbindung iiber den Fieldbus-Bus exi- 
stiert. Wenn es gewiinscht wird, kann die Schnittstellenkarte 
40 diese Vorrichtungs- und Segmentstatusdateii an den Kon- 
troller (oder andere Vorrichtung) fUr Diagnosezwecke sen- 
den. 

Ferner kann die Schnittstellenkarte 40 die Konmiunika- 
tion und den Zeitsteuerstatus eines Fieldbus- Segments fiir 
Diagnosezwecke iiberwachen. Insbesondere kann die 
Schnittstellenkarte 40 automatisch an den Daten teilhaben, 
die durch die Bereichs vorrichtungen auf dem Fieldbus-Bus 
veroffentlicht werden, und kann die empfangenen Daten 
analysieren, um beispielsweise Zeitsteuerprobleme oder an- 
dere Probleme auf dem Fieldbus-Bus zu ermitteln. Wenn es 
gewiinscht wird, kann die Schnittstellenkarte 40 die ankom- 
menden Daten zeitlich pragen und speichem und dann Stati- 
stiken aufbewahren, die jedeh Funktionsblock^ oder Vorrich- 
tung betreffen, der oder die ah den Bus angeschlossen ist 
und/oder Statistiken aufbewahren, die das Segment des Bus- 
ses betreffen. Beispielsweise kann die Schnittstellenkarte 40 
die minimalen und inaximalen Zeiten zwischen Datener- 
neueningen bestimmen, und zwar fur bestimmte publizierte 
Daten, urid kann bestimmen, ob diese Zeiten innerhalb eines 
zulassigen Bereiches liegen, um festzustellen, ob Kommuni- 
kationsprobleme existieren. Li ahnlicher Weise kann die 
Schnittstellenkarte 40 die Zeiten, zu welchen bestinomte Da- 
ten angenommenermaBen auf dern Bus .zu veroffentlichen 
sind, mit der tatsachlichen Zeit vergleichen, zu welcher 
diese Daten auf dem Bus veroffentlicht werden, kann ver- 
bfauchte Datenzahlwerte fiir die Funktionsblocke oder Vor- 
richtungen uberwachen und kann iigendwelche anderen ge- 



wunschten Statistiken aufbewahren, um Zeitsteuerungs- 
oder andere Kommunikationsfehler auf dem Bus zu detek- 
tieren. NatiirHch konnen irgendwelche anderen publizierten 
Daten uberwacht werden, um die Kommunikations- oder 
5 Zeitsteuerprobleme auf dem Bus zu bestimmen. Wie oben 
dargelegt wurde, konnen die statistischen Informationen, die 
durch die Schnittstellenkarte 40 erzeugt oder gespei chert 
werden, fiir irgendeinen Funktionsblock, Vorrichtung oder 
Segment des Busses aufbewahrt werden und konnen zu dem 
10 Kontroller (oder irgendeiner anderen Vorrichtung) fiir Dia- 
gnosezwecke gesendet oder von dem Kontroller gelesen 
werden. 

Fig. 6 veranschaulicht ein HuBdiagramm 200, welches 
den Weg anz^igt, in welchem ein Schattenfunktionsblock 
15 innerhalb des KontroUers 12 erstellt werden kann. Wahrend 
die RuBdiagramme der Fig. 6-12 eine Anzahl von Blocken 
veranschaulichen, sei darauf hinge wiesen, daB diese Blocke 
lediglich eine Sequenz von Schritten angeben, die auszufuh- 
ren sind, und daB die Schritte in der Software oder in iigend- 
20 einer anderen gewunschten Weise ausgefiihrt werden kon- 
nen. Die FIuBdiagranmiblocke der Fig, 6-12 stellen jedoch 
nicht notwendigerweise Funktionsblocke oder KontroUer- 
blocke dar, ahnliche den Funktionsblocken, die in Fig. 4 
veranschaulicht sind. 
25 Bei einem Block 201 empfangt der Kontroller 12 ein Mo- 
. dul-InstaUationsskript von der Anwenderworkstation, die 
auf einem der PCs 14 von Fig, 1 bestehen kann. Das Modul- ' 
Installationsskript wird durch das Konfigurationswerkzeug . 
erzeugt, welches durch die Anwenderworkstation ablauft 
30 Oder auf dieser Anwenderworkstation lauft, und enthalt alle 
Informationen, die erforderlich sind, um die Objekte (in ei- 
ner objektorientierten Programmiarsprache) zu ersteUen, die 
den Funktionsblocken eines Steuermoduls in dem Kontrol- 
• ler 12 zugeordnet sind. Das heiBt, das Installationsskript 
35 konfiguriert die Blocke (wie beispielsweise die Funktions- 
blocke, die dem Stetiermodul 100 von Fig. 4 zugeordnet 
sind) und die Verbindungen zwischen solchen Blocken, die 
durch die Verbindungen (Links) definiert sind. Natiirlich 
werden all diese Informationen durch den Anwender geHe- 
40 fert, wahrend dieser das Konfigurationswerkzeug verwen- 
det. Wenn ein Funktionsblock durch einen extemen Funk- 
tionsblock zu implementieren ist, wie beispielsweise einen 
in einer Bereichsvorrichtung, erzeugt ein Block 202 einen 
Schattenfunktionsblock innerhalb des Kontroller 12, und 
45 zwar durch Eirzeugen eines Objektes (innerhalb einer ob- . 
jektorientierten Programmiersprache), welches ahnlich ist 
den Funktionsblocken fiir andere Vorrichtungen, die inner- 
halb des KontroUers gelegen sind, ausgenommenen dieses 
fuhrt keinerlei Steuerfunktioneri durch. Wahrend die Schat- 
50 tenfunktibnsblocke in bevorzugter Weise als ein Objekt in 
einer objektorientierten Prograinmierumgebung erzeugt 
werden, konnen sie unter Verwendung irgendeiner anderen 
Programmierumgebung erzeugt werden, die dem Kontroller 
12 zugeordnet ist oder von diesem verwendet wird. 
55 Wenn ein Schattenfunktionsblock aufgebaut wird, veran- 
laBt der Block 202 die Schnittstellenkarte 40, den tatsachli- 
chen Funktionsblock innerhalb der Fieldbus- Vorrichtung 
abzutasten und Informationen von dem tatsachlichen Funk- 
tionsblock zu erhalten, die erforderlich sind, um zu Beginn 
60 den Schattenfunktionsblock zu konfigurieren. Ferrier erstellt 
der Block 202 die DatenbanksteUen innerhalb der unteren 
Datenbank 156 des KontroUers 12, an die die Schnittstellen- 
' karte 12 Betrachtungsobjekt- und Wamobjektdaten als auch 
verkettete Parameterdaten eingeben sollte, die von dem tat- 
65 sachlichen Funktionsblock erhalten werden. Der Block 202 
infofmiert auch die SchnittsteUe.40 dariiber, wie oft Be- 
trachtungsobjekt- und WamobjektinformationMi basierend 
auf der Abtastrate des Moduls 100 angefragt werden soUen. 
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Nachdem der Block 202 einen Schattenfunktionsblock.in 
dem Koatroller erzbugt hat.und die geeigneten Verbindun- 
gen zwischen der Datenbank 156, dem Schattenfiinktions- 
block 108 und der Schnittstellenkarte 40 identifiziert hat, 
konfiguriert ein Block 203 die untere Datenbasis 156, um 
die gespeicherteri verketteten Parameterdaten (das heiBt die- 
jenigen, die durch die Schnittstellenkarte 40 unter Verwen- 
dung des synchronen VeroffentlicherATeilnehmer-VCRs er- 
halten wurden) an den Schattenfiinktionsblock zu liefem, 
anstelle der Daten, die fur die verketteten Parameter unter 
Verwendung der Objektoperation erhallen werden. Dies ist 
erforderlich, um sicherzustellen, daJ3 die zuletzt erstellten 
Daten fiir die verketteten Parameter (das heiBt diejenigeri, 
die durch die synchronen Kommunikationen in dem Field- 
bus-Netzwerk erhalten wurden) dem Schattenfunktions- 
block 108 angeboten werden anstelle der Daten, die fiir 
diese Parameter .unter Verwendung der Betrachtungslisten- 
operation erhalten werden (was asynchron erfolgt); 

Wenn ein Steuermodul, der einen Schattenfiinktionsblock 
. verwendet, zu Beginn konfiguriert wird, muB das Fieldbus- 
Kommunikationsnetzwerk ebenfalls konfiguriert werden, 
um die erforderhchen- synchronen und asynchronen Nach- 
richtenubertragungen zwischen dem aktuellen Funktions- 
block 112 und dem.Schattenfunktionsblbck 108 zu unter- 
stiitzen. Die Fig.; 7-12 veranschaulichen RuBdiagramme, 
weiche die Schritte herausgreifen, die beim Konfigurieren 
des Fieldbus-Netzwerks involviert sind, um die Schatten- 
fiinktionsblocke zu unterstiitzen. Wahrend die Fig. 7-10 als 
getrennte FluBdiagramme dargestellt sind, konnen sie 
gleichzeitig oder nahezu gleichzeitig ausgefiihrt werden. 

Fig. 7 zeigt ein RuBdiagramm 210, welches dazu ver- 
wendet werden kann, einen verbindungsaktiven Plan oder 
Ablaufsteuening in dem Fieldbus-Netzwerk zu erstellen. 
Ein Block 211 innerhalb, des Kontrollers 12 empfangt das 
LAS-Plan-Installationsskript, wie es durch das Konfigurati- 
onswerkzeug fiir das Fieldbus-Kommunikatipnsnetzwerk 
entwickelt wurde, urid zwar nach Inbetrachtziehung aller 
synchroner Nachrichteniibertragungen, die iiber den Field- 
bus-Bus stattfinden miissen, inklusive solcher, die fiir die 
Schattenfunktionsblocke erforderlich sind. Natiirhch kann 
dieses. Installationsskript unter Verwendung bekannter 
Werkzeuge erzeugt werden, die fiir das Fieldbus-Kommuni- 
kationsprotokoU verfiigbar sind, die auch in dem Konfigura- 
tionswerkzeug des Kontrollers 12 integriert sein konnen. 
Ein Block 212 iristialliert dann dien LAS-Plan (Abwickler) an 
dem angepeilten Fieldbus-Port, der beispielsweise die 
Schnittstellenkarte 40 aus Fig. 5 sein kann. 

Danach erzeugt ein Block 213 automatisch Teilnehmer- 
verbindungen und VCRs innerhalb des Fieldbus-Netzwerks 
basierend auf den Daten, die durch die Fieldbus-Vorrichtun- 
gen verofifentlicht- werden; Speziell werden diese Teilneh- 
merverbindungen derart erzeugt, daB die Schnittstellenkarte 
40 teil hat an den verketteten Parametem der Fieldbus- 
Funktionsblocke, fiir Schattenfunktionsblocke innerhalb des 
Kontrollers 12 existieren. In ahnUcher Weise gibt die 
Schnittstellenkarte 40 Daten heraus, die durch die Funk- 
tionsblocke innerhalb des Kontrollers 12 erzeugt werden 
und die zu den Schattenfunktionsblocken innerhalb des 
Kontrollers 12 als ein verketteter Parameter gesendet wer- 
den. Allgemein gesagt, agiert die Schnittstellenkarte 40 als 
ein Fiinktionsblock-Proxy fiir die verketteten Daten zu und 
von den Schattenfunktionsblocken. Femer wirkt die Schnitt- 
stellenkarte 40 als ein Funktionsblock-Proxy, um nach Be- 
trachtungsobjekt- und Wamobjektinformatiorien von den 
tatsachlichen oder aktuellen Funktionsblocken anzufiragen, 
fiir weiche Schattenfunktionsblocke existieren, um die nicht 
verketteten Daten zu emeuem, die den Schattenfunktions- 
blocken innerhalb des Kontrollers 12 zugeordnet sind. 
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Ein Block 214 bildet dann den LAS-Installationsstatus in 
, demKontroiler(oderDeltaV-)Statusab,sodaBderKontrol- 

ler 12 bestimmen kann, ob die LAS-Installation akzeptiert 

worden ist oder diirch das Fieldbus-Netzwerk abgewiesen 
5 wurde. Dies ermoglicht es dem KontroUer 12 zu verifizie- 

ren, ob die Installation des Fieldbus-Netzwerks stattgefim- 

den hat. 

Fig. 8 veranschaulicht ein RuBdiagramm 220, welches 
die Schritte zeigt, die dazu verwendet werden, um die Verof- 

10 fentlicher-Verbindungen innerhalb des Fieldbus-Netzwerks 
zu erstellen. Ein Block 221 in dem KontroUer 12 empfangt 
die Veroffentlicher-Verbindungen, die durch das Worksta- 
tion-Konfigurationswerkzeug fiir das Fieldbus-Netzwerk ei:- . 
zeugt wurden, und ein Block 222 sendet dann diese Verof- 

15 fentlicher-Verbindungen (publisher links) zu der Schnittstel- 

^ lenkarte 40, um die Veroffentlicher-Verbindungen zu erstel- 
len und auch die zugeordneten VCRs, die erforderlich sind, 
um die Schattenfiinktionsblockkommunikationen als auch 
andere Konmiunikationen auf dem Funktionsblock 42 zu 

20 unterstiitzen. 

Fig. 9 zeigt ein RuBdiagramm 230, welches die Schritte 
veranschaulicht, die der Installation einer Vorrichtungskon- 
figuration innerhalb einer Fieldbus-Vorrichtung zugeordnet 
sind. Ein Block 231 empfangt das Vorrichtungskonfigurati- 

25 ons-Installationsskript von der Workstation, konfiguriert 
durch das Konfigurationswerkzeug, nachdem aU die Verbin- 
dungs- und anderen Informationen fiir diese ^forrichtung er- 
steUt worden sind. Ein Blocli 232 loscht dann die firuhere 
Konfiguration in der Vorrichtung, indem sie geeignete Be- 

30 fehle zu der Vorrichtung iiber die Schnittstellenkarte 40 sen- 
det. Wahrend es nicht strikt erforderlich ist, wurde es als 
wiinschenswert gefunden, die friihere Vorrichtungskonfigu- 
ration zu loschen, bevor versucht wird, eine neue Vorrich- 
tuhgskonfiguration in der Fieldbus-Vorrichtung zu installie- 

35 ren, um dadurch InstaUati9nsprobleme zu vermeiden, 

Ein Block 233 instaUiert dann die VCRs und ein Block 
234 instaUiert die Verbindungen, die, erforderlich sind, um 
die Konimunikation gemaB dem verbindungsaktiven Plan 
und die Veroffentlicher/Teilnehmerbeziehungen, die fiir das 

40 Fieldbus-Netzwerk erstellt wurden, zu implementieren. Ein 
Block 235 instaUiert dann die Fieldbus-Startliste in der Vor- 
richtung, was die Funktionsblock-ProgrammausfUhrung 
von dieser Vorrichtung mit der Programmausfiihrungen von 
anderen Funktionsblocken in anderen Vorrichtungen des 

45 Reldbus-Netzwerks synchronisiert. Danach instaUiert ein 
Block 236 den Makrozyklus der Vorrichtung, nachdem die- 
ser Makrpzyklus berechnet worden ist oder bestimmte wor- 
den ist, um aU den synchronen Kommunikationen Rech- 
nung zu tragen, die zwangsweise iiber den Bus 42 stattfin- 

50 den miissen, welcher dem Fieldbus zugeordnet ist. 

. Fig. 10 zeigt ein FluBdiagramm 240, welches die Schritte 
veranschauUcht, die dazu verwendet werden, um einen spe- 
zieUen oder bestimmten Funktionsblock innerhalb einer be- 
stimmten Vorrichtung innerhalb des Fieldbus-Netzwerks zu 

55 ersteUeri. Ein Block 241 empfangt zuerst ein Funktions- 
block-InstaUationsskript, wie es durch das Konfigurations- 
werkzeug entwickelt wurde. Ein Block 242 instaUiert dann 
den nachsten Funktionsblock und Progranunausfiihrungspe- 
riodenparameter, wie dies in typischer Weise vorgenommen 

60 wird, wenn ein Fieldbus-Funktionsblock konfiguriert wird; 
Danach setzt ein Block 243 den Funktionsblockmodus au- 
Ber Service, was erforderlich ist, uni die Werte innerhalb des 
Funktionsblockes zu andem. Ein Block 244 instaUiert dann 
die gemaB dem Funktionsblockparameter konfigurierten 

65 Werte oder die Anwenderprioritaten (overrides) (das heiBt 
die anwenderdefinierten Werte) innerhalb des Funktions- 
blockes. Diese durch deri Anwender konfigurierten Werte, 
'' konnen in irgendeiner Weise ersteUt werden, wie beispiels- 
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weise durch die Verwendung von Dialogboxen in der Work- 
station wahrend der Konfiguration des ProzeBregelsy stems, 
panach stellt ein Block 245 den Funktionsblockmodus auf 
den konfigurierten Wert , ein, so daB der Funktionsblock in 
Einklang mit der Art arbeitet, in welcher dieser konfiguriert 5 
ist. 

Es sei darauf hingewiesen, daB die FluBdiagramme der 
Fig. 7-9 lediglich die normalen Schritte angeben, die dazu 
verwendet werden, um ein Fieldbus-Netzwerk zu konfigu- 
rieren. In diesem Fall tragt jedoch die Erstellung des Field- lO 
,bus-Netzwerks Rechnung hinsichtlich der und enthalt die 
Veroffentlicher/Teilnehmerverbindungen und VCRs, die er- 
forderlich sind, um den Betrieb von irgendeinem der Schat- 
tenfunktionsblocke innerhalb des KontroUers 12 zu unter- . 
stiitzen. Natiirlich kann die Anwenderworkstation oder der 15 
KontroUer 12 das Fieldbus-Netzwerk automatisch konfigu- 
rieren, basierend auf den Informationen, die durch den An- 
wender iiber die Erstellung des Regelsystems wahrend der 
Konfiguration dieses Systems geliefert werden. 

GemaB Fig,. 11 veranschaulicht ein RuBdiagramm 250 20 
die Betriebsweise eines Schattenfunktionsblockes, wenn ein 
Steuermodul, der diesen Schattenfiinktionsblock enthalt, auf 
dem KontroUer 12 lauft, um die ProzeBsteuerung oder ^rege- 
lung durchzufuhren. Wie zu erkennen ist, implementiert der 
KontroUer 12 die Blocke innerhalb eines bestinmiten Mo- 25 
duls (wie beispiels weise die Blocke 102, 104, 106 und 108 
von Fig. 4) in der Modulabtastrate, die dem Modul zugeord- 
net ist. Die Kommunikation von verketteten Daten (wie den- 
jenigen, die durch die Verbindungen in dem Diagramm von 
Fig. 4 definiert sind) zwischen den aktueUen Fieldbus-Funk- 30 
tionsblocken lind den Schattenfunktionsblocken erfolgt in 
der synchronen Makrozyklusrate des Fieldbus-Netzwerks, 
die verschieden sein kann von der Modulabtastrate des Kon- 
troUers .12. Als ein Ergebnis werden die Daten fiir die ver- 
ketteten Parameter in typischer Weise in der unteren Daten- 35 
bank 156 des KontroUers 12 in einer unterschiedlichen (ge- 
wohnUch schneUeren) Rate als die Daten fur nicht verkettete 
Parameter gespeichert. 

Wenn der Schattenfunktionsblock in dem KontroUer 12 
. implementiert ist, tastet ein Block 252 die Betriebsdaten ab, 40 
die irineriialb der unteren Datenbank 156 des KontroUers 12 
gespeichert sind. Das heiBt, es werden wahrend jeder Mo- 
dulperiode die Betriebsdaten, die in der unteren Datenbank 
156 gespeichert wurden, durch den SchnittsteUenmodul 40 
gelesen. Ein Block 254 ermittelt, ob die Abtastung voran- ' 45 
schreitet, Wenn dies nicht der FaU ist, emeuert ein Block 
256 den Blockfehler in dem Schattenfunktionsblock, steUt 
den Schattenfiinktionsblock-Ausgangsstatus auf schlecht 
ein und steUt die Port-Integritat so ein, um dem KontroUer 
12 anzuzeigen, daB der Schattenfunktionsblock ausgefaUen 50 
ist und daB daher ein Problem in beziig auf den extemen 
Funktionsblock. oder in bezug auf Nachrichteniibertragun- 
geri mit dem extemen Funktionsblock innerhalb des Field- 
bus-Netzwerks auftreten kann. Wenn solch ein Fehler detek- 
tiert wird, werden die Schattenfunktionsblockdaten nicht er- 55 
neuert (da diese Daten alt sind oder in jedem FaU schlechte 
Daten sind) und es wird die Emeuerungsoperatipn der Daten 
innerhalb des Schattenfunktionsblocks fur diesen Modulab- 
tastzyklus angehalten, Wenn jedoch die Abtastung voran- 
schreitet, kopiert ein Block 258 die empfangenen Betriebs- 60 
daten in dem Schattenfunktionsblock. NatiirUch enthalten 
die Betriebsdaten nicht nur die Daten, die durch die Betrach- 
tungs- und Wamobjekte in der Modulabtastrate erhalten 
werden, sondem auch die Daten fur die verketteten Parame- 
ter, die erhalten wurden und in die untere Datenbank 156 in 65 
einer Rate eingeschrieben werden, die durch den Makrozy- 
klus des Fieldbus-Netzwerks festgelegt wird. 

Ein Block 260 ermittelt dann, ob der statistische Revisi- 
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onsparameter, der dem tatsachUchen Funktionsblock zuge- 
ordnet ist (der durch die Betrachtungsobjektoperation geUe- 
fert wird) zugenonmien hat. Wenn dies der FaU ist, instruiert 
ein Block 252 die SchnittsteUenkarte 40, die statischen Da- 
ten, die dem Fieldbus-Funktionsblock zugeordnet sind, zu 
lesen und diese statischen Daten zu der unteren Datenbank 
156 zu liefem, wo diese Daten gelesen werden und in den 
Schattenfunktionsblock eingesetzf werden. Wie dies be- 
kannt ist, zeigt der statische Visionsparameter an, ob irgend- 
welche statischen Daten, die normalerweise durch die stati- 
sche BetrachtungsUste vorgesehen werden, geandert wur- 
den. Wenn der statische Re visionsparameter nicht erhoht 
wurde, werden keine der statischen Daten geandert und es 
ist nicht erforderUch, diese Daten wahrend jedes Zyklusses 
des Steuermoduls zu lesen. Wenn jedoch die statische Da- 
tenrevision zugenommen hat, dann haben sich einige der 
statischen Daten geandert und es mlissen diese statischen 
Daten gelesen werden und in den Schattenfunktionsblock 
gesetzt werden, so daB der Schattenfunktionsblock die Da- 
ten spiegelt, die tatsachUch innerhalb des extemen Funk- 
tionsblocks vorhanden sind. 

Nachdem die statischen Daten erhalten worden sind oder 
die statische Revision nicht zugenommen hait, bildet ein , 
Block 264 die'Fieldbus-Alarme (und andere Daten, wenn 
dies erforderUch ist) in den Alarmen (oder anderen Datenbe- 
reichen) des KontroUers 12 ab, Diese Abbildung kann unter 
Verwendung einer NachschlagetabeUe erreicht werden oder 
durch irgendeine andere Abbildungstechnik. Die abgebilde- 
ten AlarmgroBen (und andere Daten) werden dann in dem 
Schattenfunktionsblock gespeichert, um durch andere Steu- 
erblocke des Steuermoduls verwendet zu werden. Die 
AlarmgroBen konnen auch fiir einen Anwender dargesteUt 
werden oder in irgendeiner anderen gewiinschten Weise ver- 
wendet werden. 

Danach ermittelt ein Block 266, ob die Daten fur die ver- 
ketteten Parameter veraltet sirid (das heiBt nicht mehr aktu- 
eU sirid). Solch eine Anzeige wird in regularer Weise in den 
Fieldbus-Kommunikationen erzeugt und sie zeigt an, daB 
die empfangenen Daten nicht in dem aUerletzten Makrozy- 
klus des Fieldbus-Netzwerks erzeugt wurden, was anzeigen 
kann, daB ein Zeitsteuerprobleni oder ein anderes Problem 
innerhalb des Fieldbus-Netzwerks existieren kann. Wenn 
die Verkettungsparameterdaten- veraltet sind, markiert ,ein 
Block 268 die Ausgangsdaten als BadNotConnected, was 
den Modus oder Status von anderen Funktionsblocken in- 
nerhalb des KontroUers 12 andem kann. Danach oder wenn 
die verketteten Daten nicht veraltet sind, macht ein Block 
270 die Betriebsdaten fiir andere Blocke innerhalb des Kon- 
troUers 12 sichtbar und der KontroUer 12 fahrt damit fort, 
basierend auf den neuen Betriebsdaten zu arbeiten. 

Wie ersehen werden kann, veranschauHcht das RuBdia- 
gramm von Fig, 11 die Betriebsweise der Emeuerung des 
iSchattenfunktionsblocks, um sicherzustellen, daB dieser die 
Daten spiegelt, die dem extemen Funktionsblock innerhalb 
einer extemen Vorrichtung zugeordnet sind. Jedoch kann 
der Schattenfunktionsblock auch Daten zu dem extemen 
Funktionsblock iibertragen und Schreibbefehle an den exter- 
nen Funktionsblock senden. Solche Daten und Schreibbe- 
fehle konnen von einem Anwender, beispielsweise bei einer 
Workstation, vorgesehen werden oder konnen an anderen 
Funktionsblocken innerhalb des KontroUers 12 entspringen 
und von diesen ausgesendet werden, und zwar uber die er- 
steUten Verbindungen. GemaB Fig, 12 veranschaulicht ein 
RuBdiagramm 280 die Schritte, die unteraommen werden, 
um Daten oder Schreibbefehle zu einem extemen Funk- 
tionsblock iiber den Schattenfunktionsblock zu senden. Bei 
einem Block 281 schreibt ein Steuerblock innerhalb des 
KontroUers 12 Daten iiber eine Eingangsvefbindung in den 
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Schattenfiinkdonsblock ein. Alteriiativ kann ein Anwender 
einen Schreibbefehl an den Schattenfunktionsblock iiber 
eine Aawenderschnittstelle senden, was es einem Anwender 
ermoglicht, z. B. von Hand einen SoUwert oder einen ande- 
ren Wert, der dem extemen Funktionsblock zugeordnet ist, 5 
zu andem. Der Schattenfunktionsblock sendet dann unmit- 
telbar einen Schreibbefehl oder andereDaten an die Schnitt- 
stellenkarte 40. Wenn seiche Daten oder Befehl einem ver- 
ketteten Parameter zugeordnet sind oder ist, veroffentlicht 
die Schnittstellenkarte 40 die Daten auf dem Fieldbus-Bus lO 
fiir den extemen Funktionsblock zu einem geeigneten oder 
synchronen Zeitpunkt, wie dieser durch den Makrozyklus 
des FieldbusrNetzwerks festgelegt ist. Wenn der Schreibbe- 
fehl oder die Daten nicht einem verketteten Parameter zuge- 
ordnet ist bzw. sind, verwendet die Schnittstellenkarte 40 15 
asynchrone Nachrichtentibertragungen, um den Befehl oder 
die Daten an den extemen Funktionsblock zu- iibermittebi. 
. Danach empfangt der externe Funktionsblock die Daten 
oder den Befehl und emeut deren oder dessen Attributpara- 
meter entsprechend. Diese Anderungen werden dann iiber 20 
die Schnittstellenkarte 40 unter Verwendung von Veroffent- 
licher/Teilnehmer-Kommunikationen zuruck ubertragen, als 
auch die Betrachtungsobjektoperation, und es werden die 
neuen Daten in die untere Datenbank 156 gesetzt, wo dann 
wahrend des nachsten Abtastzyklusses des Steuermoduls 25 
diese Daten in den Schattenfunktionsblock eingesetzt wer- 
den. 

Wenn der Block 282 eine Schreibanfrage an die Schnitt- 
stellenkarte 40 sendet und diese Anfrage zu dem extemen 
Funktionsblock gesendet wird, empfangt die Schnittstelleh- 30 
karte 40 eine Antwort von dem Funktionsblock, die anzeigt, 
ob der.Schreibvorgang vervollstandigt worden ist oder ob 
die Daten angenommen oder empfangen warden. Die 
Schnittstellenkarte 40 sendet ihrerseits diese Antwort zu 
dem Schattenfunktionsblock. vWenn der Schreibvorgang 35 
fehlgeschlagen ist, kann die Status-, Alarm- oder Fehlerein- 
stellung des Schattehfunktionsblocks geandert werden, uni • 
diesen Fehler zu reflektieren. Wenn beispielsweise eine 
Schreibanfrage, die einem verketteten Parameter zugeordnet 
ist, nicht empfangen wurde oder nicht richtig durch die 40 
Schnittstelle 40 implementiert wurde, kann dies in dem Feh- 
lerstatus des ' Schattenfunktionsb locks angezeigt werden. 
Wenn es gewunscht wird, wenn ein Schreibbefehl, der von 
einem Anwender stammt, fehlschlagt, implementiert zu 
werden, kann ein Block 283 eine Anzeige iiber den Fehl- 45 
schlag fiir den Anwender bei der Workstation senden oder 
zu irgendeiner anderen Anwenderschnittstelle, urn dadurch 
den Anwender iiber den fehlgeschlagenen Versuch zu unter- 
richten, in den extemen Funktionsblock zu schreiben. 

Wahrend sich die Beschreibung auf die Implementiemng 50 
und die Verwendung eines > einzelnen Schattenfunktions- 
blockes 108 gerichtet hat, sei darauf hingewiesen, daB viele 
Schattenfiinktionsblocke in dem gleichen Steuermodul oder 
Kontroller implementiert werden konnen, um es dem Steu- • 
ermodul oder KontroUer zu ermoglichen, viele exteme 55 
Funktionsblocke zu verwenden, Femer konnen Schatten- 
funktionsblocke implementiert werden unter Verwendung 
irgendeines extemen ProzeBsteuer- oder -regel-Kommuni- 
katipnsprotokolls (neben dem Fieldbus-Protokoll) und kon-: 
nen dazu verwendet werden, mit irgendeiriem Typ eines 60 
Funktionsblocks zu korhmunizieren, inklusive iigendeinem 
Funktionsblock, der ahnlich ist mit oder der gleiche ist wie 
irgendeiner der unterschiedlichen Funktionsbl5cke, die , 
durch das Reldbus-Protokoll spezifisch identifiziert und un- 
terstiitzt werden. Obwohl dariiber hinaus Schattenfunktions- 65 
blocke hier so beschrieben wurden, als ob sie einem exter- 
nen Funktionsblock zugeordnet sind, und zwar in der Form, 
in welcher das Fieldbus-Protokoll einen "Funktionsblock" 
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definiert, sei darauf hingewiesen, daB die Verwendung des 
Ausdmcks "Funktionsblock" hier nicht auf das beschrankt 
ist, was das Fieldbus-Protokoll als einen Funktionsblock de- 
finiert, sondera statt dessen irgendein anderer Typ eihes 
Blocks, Programms, einer Hardware, Firmware usw. enthal- 
ten ist, die nut irgendeinem Typ eines Steuersystems oder 
Regelsystems und/oder KommunikationsprotokoU zugeord- 
net ist und die dazu verwendet werden kann, lim eine ge- 
wisse Steuerfunktion oder Regelfunktion zu implementie- 
ren. Obwohl somit Funktionsblocke typisch die Form von 
Objekten annehmen, und zwar innerhalb einer objektorien- 
tierten Programndemmgebung, muB dies nicht der Fall sein 
und statt dessen konnen andere logische Einheiten dazu ver- 
wendet werden, um eine bestimmte Steuemng oder Rege- 
lurig (inklusive Eingabe- und Ausgabe-)Funktionen inner- 
halb einer ProzeBsteuerumgebung oder ProzeBregelumge- 
bung auszufiihren, 

Obwohl femer der Schattenfunktionsblock, der hier be- 
schrieben wurde, in bevorzugter Weise in einer Software 
implementiert wird, die beispielsweise in einem KontroUer 
oder einer anderen PrpzeBsteuervoirichtung gespeichert ist, 
kann sie alternativ oder zusatzlich in einer Hardware, Inrm- 
ware usw. in gewiinschter Weise implementiert sein. Wenn 
sie in einer Software implementiert ist, kann der Schatten- 
funktionsblock der vorliegenden Erfindung in irgendeinem 
computerlesbaren Speicher gespeichert sein, wie beispiels- 
weise einer Magnetplatte, einer Laserplatte oder einem an- 
deren Speichermedium, in einem RAM oder ROM eines 
Computers usw. In ahnlicher Weise kann diese Software an 
einen Anwender oder eine Vorrichtung aus geliefert werden, 
und zwar iiber irgendein bekanntes oder gewiinschtes Aus- 
Hefemngsverfahren, inklusive beispielsweise iiber einen 
Nachrichteniibertragungskanal, wie beispielsweise eine Te- 
lefohleitung, das Internet usw. 

Obwohl auch der Schattenfunktionsblock der vorliegen- 
den Erfindung in Einzelheiten in Verbindung mit einem Pro- 
zeBregelnetzwerk beschrieben wurde, welches die ProzeB- 
steuerfiinktionen in einer dezentralisierten oder verteilten 
Weise unter Verwendung eines Satzes von Fieldbus-Vor- 
richtungen implementiert, sei darauf hingewiesen, daB der 
Schattenfunktionsblock der vorhegenden Erfindung in Ver- 
bindung mit ProzeBregelnetzwerken verwendet werden 
kann, die Steuerfunktionen ausfiihren, .."unter Verwendung 
von anderen Typen von Bereichsyoirichtungen und Kom- 
munikationsprbtokollen, inklusive der ProtbkoUe, die auf 
anderen als den zwei Leitungsbussen basieren, und Proto- 
kollen, die analog und/oder digitale Nachrichteniibertragun- 
gen unterstiitzen. Der Schattenfunktionsblock der vorliegen- 
den Erfindung kann beispielsweise in irgendeinem ProzeB- 
regelnetzwerk verwendet werden, welches Vorrichtungen 
verwendet, die in Einklang mit dem HART-, PROFIBUS-, 
usw. KommunikationsprotokolLen oder irgendeinem ande- 
ren KommunikationsprotokoU stehen, die es nunmehr gibt 
oder die in der Zukunft entwickelt werden konnen. In ahnli- 
cher Weise kann, wenn dies gewunscht wird, der Schatten- 
funktionsblock der vorliegenden Erfindung in ProzeBregel- 
netzwerken verwendet werden, die keine verteilten Steuer- 
funktionen haben, sondem statt dessen einen zentralisierten 
KontroUer oder ein Steuer- oder Regelschema verwenden, 
um die Vorrichtungen darin zu steuera oder zu regeln. 

Wahrend die vorUegende Erfindung in bezug auf spezifi- 
sche Beispiele beschrieben wurde, die dazu dienen, die Er- 
findung ledigUch zu veranschaulichen, jedoch nicht einzu- 
schranken, ist es fiir Fachleute offensichtlich, daB Andemn- 
gen, &ganzungen oder Weglassungen bei den offenbarten 
Ausfuhrungsformen vorgenommen werden konnen, ohne 
dadurch die Idee und den Rahmen der vorliegenden Erfin- 
dung zu verlassen. 
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Patentanspriiche 

1. Interface-Furiktionsblock fur die Verwendung in ei- 
nem ProzeBkontroller, der kommunikativ mit einer ex- 
temen Vorrichtung uber ein Kommunikationsnetzwerk 5 
gekoppelt ist, wobei der ProzeBkontroller folgendes 
implementiert: 

- eine Steuerroutine unter Venyendung eines in- 
temen Funktiorisblockes, welcher innerfialb des 
ProzeBkontrollers angeordnet ist, und 10 

- einen extemen Funktionsblock, der in der ex- 
temen Vorrichtung angeordnet ist, wobei der In- 
terface-Funktionsblock folgendes aufweist: 

- einen Kommunikationsport mit einem Eingang, 
der mit dem externen Funktionsblock uber das 15 
Kommunikationsnetzwerk kommuniziert, um Da- 
ten, die den extemen Funktionsblock betrefFen, zu 
empfangen, und 

- einen Speicher, der die empfangenen Daten, die 
den extemen Funktionsblock betrefifen, gemaB ei- 20 
nem Komrnunikationsprotokoll des interaen . 
Funktionsblockes speichert. 

2. Interface-Funktionsblock nach Anspruch 1, der fer- 
ner einen Ausgang umf aBt, der die Daten, die den ex- 
temen Funktionsblock betreffen, an den intemen Funk- 25 
tionsblock gemaB dem Komrnunikationsprotokoll des 
internen Funktionsblockes liefert. 

3. Interface-Funktionsblock nach Anspruch 2, bei dem 
der Eingang des Koramunikationsports die Daten, die 
den extemen Funktionsblock betreffen, unabhangig 30 
von der Operation des intemen Funktionsblockes emp-' 
fangt. 

4. Interface-Funktionsblock nach Anspmch 2, bei dem 
der exteme Funktionsblock iiber das Kommunikations- 
netzwerk unter Verwendung eines ersten Konraiunika- 35 
tionsprotokolls kommuniziert, welches verschieden ist 
von einem zweiten Komrnunikationsprotokoll, das 
dem KonfigurationsprotokoU des intemen Funktions^ 
blpckes zugeordnet ist und bei dem der Eingang des 
Kommunikationsports mit dem extemen Funktions- 40 
block unter Verwendung des ersten Kommunikations- 
protokoUs kommuniziert und da: Ausgang mit dem in- 
temen Funktionsblock gemaB dem zweiten Komrnuni- 
kationsprotokoll kommuniziert. 

5. Interface-Funktionsblock nach Anspmch 4, bei dem 45 
das erste Komrnunikationsprotokoll ein Fieldbus- 
KommunikationsprotokoLL ist und bei dem der Eingang 
des Kommunikationsports mit dem extemen Funk- 
tionsblock unter Verwendung des Heldbus-Konimuni- 
kationsprotokolls konmiuniziert 50 

6. Interface-Funktionsblock nach Anspmch 5, bei dem 
der Eingang des Kommunikationsports eine Schnitt- 
steUen vorrichtung verwendet, die konfiguriert ist, um 
mit der extemen Vorrichtung uriter Verwendung des 
Fieldbus-Kommunikationsprotokolls zu kommunizie- 55 
ren, um mit dem extemen Funktionsblock zu kommu- 
nizieren. 

7. Interface-Funktionsblock nach Anspmch 1, bei dem 
der Kommunikationsport mit dem extemen Funktions- 
block unter Verwendung synchroner Nachrichtenuber- 60 
tragungen kommuniziert. • 

8. Interface-Funktionsblock nach Anspmch 1, bei dem 
der Kommunikationsport mit dem extemen Funktions- 
block unter Verwendung synchroner und asyrichroner 
Nachrichteniibertragungen kommuniziert. 65 . 

9. Interface-Funktionsblock nach Anspmch 1, bei dem 
die exteme Vorrichtung unter Verwendung eines Vor- 
richtungskommunikationsprotokoUs Nachrichten iiber- 



raittelt, welches die Kommunikation von logisch ver- 
ketteten Paketen vori Daten unter Verwendung von 
standardisierten Kommunikationsanmfen unterstiitzt 
und bei dem der Kommunikationsport mit dem exter- 
nen Funktionsblock unter Verwendung der standardi- 
sierten Kommunikationsanmfe kommuniziert, die dem 
Vorrichtungskommunikationsprotokoll zugeordnet 
sind. 

10. Interface-Funktionsblock nach Anspmch 9, bei 
dem das VorrichtungskommunikationsprotokoU ein 
Fieldbus-KommunikationsprotokoLL ist und bei dem 
der Kommunikationsport mit der extemen Vorrichtung 
unter Verwendung von Betrachtungsobjekten innerhalb 
des . Fieldbus-KommunikationsprotokoUs kommuni- 
ziert. 

11. Interface-Funktionsblock nach Anspmch 1, bei 
dem der Konomunikationsport eine Alarmanzeige von 
dem extemen Funktionsblock empfangt und bei dem 
der Speicher die empfangene Alarmanzeige speichert. 

12. Interface-Funktionsblock nach Anspmch 1, bei 
dem der Konomunikationsport femer einen Ausgang 
enthalt, welcher Daten zu dem extemen Funktions- 
block unter Verwendung eines Kommunikationsproto- 
koHs sesndet, welches dem extemen Funktionsblock zu- 
geordnet ist. 

13. Kontroller, der dafiir ausgebildet ist, um kommuni- 
kativ an eine Vielzahl von Bereichsvorrichtungen ge- 
koppelt zu werden, wobei eine der Bereichsvorrichtun- 
gen einen extemen Funktionsblock enthalt, der unter 
Verwendung eines Vorrichtungskommunikationsproto- 
kolls Nachricht ubertragt, wobei der Kontroller folgen- 
des aufweist: 

einen Prozessor; 
einen Speicher, und 

eine Steuerroutine, die in dem Speicher gespeichert ist 
und durch den Prozessor implementiert wird, um die 
Vielzahl der Bereichsvorrichtungen zu steuem, wobei 
die Steuerroutine folgendes enthalt: 

- eine Vielzahl von miteinander verbundenen in- 
temen Funktionsblocken, die so konfiguriert sind, 
um' ein KontroLLerprotokoU zu verwenden und 
durch den Kontroller implementiert sind, und 

- einen Interface-Funktionsblock, der mit einer 
der Vielzahl der miteinander verbundenen inter- 
nen Funktionsblocke unter Verwendung des Kon- 
troUerprotokolls kommuniziert, und der mit dem 
extemen Funktionsblock innerhalb einer der Be- 
reichsvorrichtungen unter Verwendung des Vor- 
richtungskonmiunikationsprotokolis kommuni- 
ziert, wobei der Interface-Funktionsblock Daten 
speichert, die den extemen Funktionsblock betref- 
fen, welche von dem extemen Funktionsblock 
empfangen wurden. 

14. KontroUer nach Anspmch 13, bei dem der Inter- 
face-Funktionsblock die Daten, die den extemen Funk- 
tionsblock betreffen, unabhangig von der Operation 
der Vielzahl der intemen Funktionsblocke empfangt. 

15. Kontroller nach Anspmch 13, bei dem das Vor- 
richtungskommunikationsprotokoU ein Fieldbus-Kom- 
munikationsprotokoU. ist und bei dem der Interface- 
Funktionsblock mit dem extemen Funktionsblock un- 
ter Verwendung des Fieldbus-Kommunikationsproto- 
koUs kommuniziert. 

16. Kontroller nach Anspnich 15, bei dem der Inter- 
face-Funktionsblock mit dem extemen Funktionsblock 
unter Verwendung von Betrachtungsobjekten innerhalb 
des Fieldbus-Kommunikationsprotokolls kommuni- 
ziert. 
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17. KontroUer nach Anspruch 15, bei dem der Inter- 
face-Funktionsblock mit dem extemen Funktionsblock 
unter Verwendimg von TeiLnehmer /Herausgeber- 
Nachrichtenubertragungen innerhalb des Fieldbus- 
KommunikationsprotokoUs kommuniziert. . 5 . 

18. KontroUer nach Anspruch 13, bei dem der Inter- 
face-Funktionsblock Daten, welche die Eingangsgro- 
Ben und AusgangsgroBen des extemen Funktionsblok- 
kes betreffen, empfangt und speichert. 

19. ' kontroller nach Anspruch 13, bei dem der Inter- lO 
face-Funktionsblock Daten, die AlanngroBen betref- 
fen, welche durch den extemen Funktionsblock erzeugt 
wurden, empfangt und speichert. 

20. KoiitroUer nach Anspruch 13, bei dem der Inter- 

. face-Funktionsblock Daten, die den Modus des exter- 15 
nen Funktionsblockes betreffen, empfangt und spei- 
chert. 

21. Kontroller nach Anspruch 13, bei dem der Inter- 
face-Funktionsblock Daten, die durch eine der ^^elzahl 
der interaen Funktionsblocke erzeugt wurden, zu dem 20 
extemen Funktionsblock sendet. 

22. KontroUer nach Anspruch 13, bei dem der Inter- 
face-Funktionsblock einen Befehl, der durch den Kon- 
troUer erzeugt wurde, zu dem extemen Funktionsblock 
sendet. ■ 25 - 

23. Verfahren zum Implementieren einer Steuer- oder 
Regelroutine in einem ProzeBkontroUer, der kommuni- 
kativ mit einer Bereichsvorrichtung gekoppelt ist, wo- 
bei die Bereichsvorrichtung einen extemen Funktions- 
block aufweist, der in ihr angeordnet ist und unter Ver- 30 
wendung eines Vorrichtungskonununikationsproto- 

. koUs Nachrichten ubertragt, wobei das Verfahren die 
folgenden Schritte umfaBt: 

- Speichem einer Vielzahl von miteinander ver- 
bundenen internen Funktionsblocken in dem Kon- 35. 
troUer, dergemaB einem KontrolIerprotokoU kon- 
figuriert ist, um diese als Teil der Steuer- oder Re- 
gelroutine zu implementieren; 

- Erzeugen eines Interface-Funktionsblockes in- 
nerhalb des KontroUers, der gemaB dem Kontrol- 40 

' lerprotokoU konfiguriert ist, wobei der Interface- 
Funktionsblock mit dem extemen Funktionsblock 
unter Verwendurig des Vorrichtungskommunikati- 
onsprotokoUs kommuniziert; 

- Erzeugen einer Steuer- oder Regelroutine, wel- 45 
che die Vielzahl der miteinander verbundenen in- 
ternen Funktionsblocke und den Interface-Funk- 
tionsblock verwendet, um den ProzeB zu steuern 
oder zu regain; und 

- Speichem von Daten in dem InterfacerFunk- 50 
tionsblock wShrend der Implementierung der 
Steuer- oder Regelroutine, die dem externen 
Funktionsblock zugeordnet sind und von diesem 
empfangen werden. 

24. Verfahren nach Anspruch 23, welches feimer den 55 
Schritt der Verwendung des Interface-Funktionsblok- 
kes ftir eine Konunuriikation mit dem extemen Funk- 
tionsblock aufweist, um Daten, die dem extemen Funk- 
tionsblock zugeordnet sind, unabhangig von der Ope- 
ration der intemen Funktionsblocke zu emeuein. .60 

25. Verfahren nach Anspmch 23, welches femer den 
Schritt einer Verwendung des Interface-Funktionsblok- 
kes umfaBt, um weitere Daten zu dem extemen Funk- 
tionsblock zu iibertragen, um die Konfiguration des ex- 
temen Funktionsblockes zu ander'n. 65 

26. Verfahren nach Anspruch 23, welches femer fol- 
gende Schritte enthalt: 

- einem Anwenda: erlauben, die Steuer- oder Re- 
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gelroutine dadurch zu konfigurieren, indem jeder 
eine Anzahl von Funktionsblocken, die in der 
Steuer- oder Regelroutine zu verwenden sind, 
spezifiziert wird, 

- die Verbindungen zwischen den spezifizierten 
Funktionsblocken, die in der Steuer- oder Regel- 
routine zu verwenden sind, zu identifizieren, und 

- die Lage eines bestimmten spezifizierten Funk- 
tionsblockes als einen intemen Funktionsblock zu 
spezifizieren, der in dem KontroUer implementiert 
ist, oder als extemen Funktionsblock zu spezifi- 
zieren, der durch die Bereichsvorrichtung imple- 
mentiert ist. 

27. Verfahren nach Anspmch 26, bei dem der Schritt 
der Spezifizierung der Lage des bestinunten spezifi- 
zierten Funktionsblockes als den extemen Funktions- 
block den folgenden Schritt aufweist: 

• - Auswahlen einer extemen Vorrichtung, in wel- 
cher der exteme Funktionsblock zu implementie- 
ren ist, aus einer Liste von externen Vorrichtun- 
gen, die an den KontroUer angeschlossen sind. 

28. Verfahrai nach Anspmch 23, bei dem der Schritt 
der Speichemng der Daten, die dem extemen Funk- 
tionsblock zugeordnet sind, den folgenden Schritt auf- 
weist: 

- Speichem einer Alarmanzeige, die durch den 
extemen Funktionsblock in dem Interface-Funk- 
tionsblock erzeugt wird, 

und bei dem das Verfahren des weiteren folgenden 
Schritt aufweist: • ■ . 

- Verwendung der Alarmanzeige, die in dem In- 
terface-Funktionsblock gespeichert ist, zum Trig- 
gem einer Alarmverarbeitung innerhalb des Kon- 
troUers. 

29. Verfahren nach Anspruch 23, \yelches femer den 
folgenden Schritt aufweist: 

- DarsteUung der Steuer- oder Regelroutine 
durch DarsteUen einer Wiedergabe der interaen 
Funktionsblocke, einer Wiedergabe des Interface- 
Funktionsblocks und von Wiedergaben der Ver- 
bindungen zwischen den intemen Funktionsblok- 
ken und den Interface-Funktionsblocken, so daB 

. der Interface-Funktionsblock den extemen Funk- 
tionsblock reprasentiert. 
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